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ABSTRACT 


In  1977  the  ACM  Special  Interest  Croup  for  Graphics 
(SICGRAPH)  formed  the  Graphics  Standards  Planning  Committee 
(GSPC)  to  develop  a  standard  for  the  industry.  The  result  of 
tnelr  efforts  was  the  COBB  graphics  system.  This  study 
discusses  that  system  and  the  issues  involved  in  its 
creation.  It  describes  Bell  Northern  Research's  approach  to 
Implementing  CORS  with  their  Virtual  Graphics  Machine  (TGM). 

Tne  installation  of  VGM  at  the  Naval  Postgraduate 
School  on  a  PDP  11/50  with  the  RSX-11M  operating  system  is 
described  as  well  as  the  initial  efforts  to  expand  it  to 
drive  the  Ramtefc  RM-9400  Graphics  Display  System.  — 
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I.  INTRODUCTION 


Computer  graphics  Is  a  relatively  young  teennology  and 
Is  expanding  at  an  extremely  rapid  rate.  As  a  recognized 
discipline,  it  marks  its  birtn  iritn  Ivan  I.  Sutherland's 
SKETCHPAD ,  in  1962.  As  tne  field  has  expanded,  hardware  has 
developed  alone  several  different  lines.  The  available 
devices  range  from  computer  driven  mechanical  pen  and  ink 
and  photoeraphlc  film  plotters,  to  refresh  display  devices 
where  digital  stored  Images  are  repeatedly  painted  on  a 


television-like 

Cathode  Ray 

Tube 

(CRT).  There  are 

also 

storage 

tube  displays  where 

the 

CRT  itself 

retains 

the 

image. 

thereby 

eliminating 

the 

need  for 

storage 

and 

continuous  refreshing.  The  latest  development  nas  been  the 
raster-scan  devices  where  a  matrix  of  intensity  values  is 
output  to  a  refresn  type  CRT. 

The  software  supporting  these  various  devices  has 
developed  along  lines  as  diverse  as  the  nardware.  Despite 
wide  variation  la  device  capabilities  there  is  a  large  body 
of  graphics  methodology  that  is  common  to  all  display 
systems.  The  existence  of  this  body  of  shared  technology 
has  contributed  significantly  to  the  movement  toward  tae 
development  of  a  software  system  that  would  be  common 
throughout  the  community  of  graphics  programmers. 
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The  concept  of  a  standardized  graphics  system  is  not  a 
new  one.  The  publication  of  the  ACM-SIGGRAPH  Graphics 
Standards  Planning  Committee  (GSPC)  report  in  19?? ,  However, 
was  the  first  widely  accepted  effort  in  the  area  of 
standardization.  This  CORK  graphics  system  is*  as  yet,  only 
a  proposal.  COES  is  envisioned  by  the  GSPC  to  be  a  first 
step  toward  a  true,  industry-wide  standard.  ?ne  nope  for  tne 
current  CORE  system  is  that  it  will  be  Implemented  at  a 
large  number  of  computer  graphics  installations  and  be 
subjected  to  a  variety  of  applications.  Such  widespread  use 
of  CORK  is  the  best  way  to  fully  challenge  the  proposed 
standard.  Extensive  use  of  the  system  will  build  a 
comprehensive  body  of  knowledge  about  it  and  should 
nlgnllgnt  its  strengths  and  weaknesses.  Based  on  sucn 
experience  the  system  can  be  revised  and  restructured  as 
necessary  until  ultimately  it  is  accepted  as  a  viable 
industry-wide  standard. 

This  project  is  intended  to  be  an  initial  step  toward  a 
tnorough  study  of  the  CORE  graphics  system  at  tne  Naval 
Postgraduate  School.  The  long  term  goal  of  the  research  is 
to  implement  the  GSPC  proposed  system  on  tne  graphics 
facility  at  the  Naval  Postgraduate  School  and  critically 
examine  its  performance. 

When  this  research  was  begun,  exposure  to  CORE  at  the 
Naval  Postgraduate  School  was  limited  to  the  information 
available  in  the  literature.  No  version  of  it  was 


operational  at  the  facility.  It  was  expected  tnat  the 
progress  of  tne  wort  would  be  slow  wnile  experience  wltfi 
CORK  was  being  accumulated.  Since  this  study  was  the  initial 
step,  tne  empnasls  was  placed  on  producing  a  good  foundation 
for  work  tnat  would  follow. 

Naturally,  the  first  step  in  the  study  of  CORE  was  to 
implement  a  version  of  it.  fne  PDP-11/50  computer  and  RSX- 
11M  operating  system  were  the  target  environment  for  this 
pease.  The  CORE  software  was  Bell  Northern  Research's 
Tlrtnal  Graphics  Machine  (TSM1 .  which  was  donated  by  that 
company  to  the  Naval  Postgraduate  School  for  research 
purposes.  4  detailed  report  on  the  system  installation  is 
presented  in  Appendix  A. 

An  intermediate  goal  of  the  project  is  to  extend  the 
newly  installed  CORE  system  to  a  variety  of  devices.  Toward 
this  end  the  initial  steps  were  taken  to  incorporate  an 
Interface  with  the  Ram t ex  RM-9400  graphics  display  system 
into  the  CORE  software.  Appendix  B  describes  this  portion  of 
tne  research. 

As  part  of  building  a  knowledge  base  for  later 
research,  tne  CORE  system  and  its  development  are  discussed 
in  detail.  The  discussion  is  intended  to  give  enough  of  an 
overview  of  tne  system  so  that  tne  reader  will  not  need  to 
refer  to  the  source  documents  except  for  essential  details. 
An  examination  of  the  relationship  between  TOM 
implementation  and  the  CORE  specification  is  also  provided. 


II.  HISTORY 


k •  THE  PROBLEM  OP  NOB-STAflDARDIZED  GRAPHICS  SYSTEMS 

Until  the  mid  1970 's  individual  graphics  devices  were 
operated  vltn  tnelr  ovn  specialized  software  systems  and 
their  instruction  sets  were  tailored  to  their  own  particular 
capabilities.  Programming  techniques  generally  were 
constrained  by  the  device  characteristics.  Even  program 
structure  could  be  dictated  by  the  available  graphics 
system.  Added  to  these  restrictions  would  be  additional 
requirements  associated  with  installation  computing  hardware 
and  operating  systems.  Such  highly  individualized  equipment 
meant  that  each  graphics  system  required  specialized 
programs,  and,  in  general,  these  were  applicable  for  that 
installation  and  no  other. 

As  tne  field  of  computer  graphics  expanded,  sucn 
limitations  became  a  real  liability.  The  inability  to  use 
one  program  at  more  tnan  one  installation  meant  that  for  a 
given  application  a  new  set  of  software  would  have  to  be 
developed  individually  for  each  combination  of  hardware  and 
operating  system.  The  issue  of  non-portability  eventually 
became  an  overriding  concern  of  the  industry. 

If  the  programs  for  particular  devices  were 
individualized  then  so  was  the  training  of  the  programmers. 
Every  device  required  users  to  nave  fairly  extensive 
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knowledge  of  its  operation.  Rather  than  concentrate  on 
eraphlcs  in  a  broad  spectrum*  application  programmers  got 
involved  in  very  low  level,  highly  detailed  programming  for 
a  specific  device.  This  meant  that  much  of  the  knowledge  and 
techniques  developed  by  a  programmer  might  be  unuseable  if 
the  device  were  changed.  Thus*  a  hardware  change  brougnt 
with  it  the  necessity  for  an  in-depth  training  program  on 
the  new  device.  Further,  the  programmer  would  now  nave  to 
keep  tne  operating  details  of  each  device  separate  In  his 
mind.  Confusion  of  such  details  is  highly  conducive  to  the 
introduction  of  additional  bugs  into  programs. 

The  prospect  of  working  in  a  very  restricted  environment 
and  of  being  required  to  assimilate  and  differentiate  a  host 
of  ldlosynchrasles,  mnemonics,  formats  and  operational 
details  no  doubt  caused  many  potential  graphics  application 
programmers  to  turn  to  other  fields  of  specialization.  The 
graphics  Industry  must  count  this  to  its  detriment. 

Another  problem,  perhaps  not  quite  as  visible  as  the 
portability  Issues,  but  certainly  as  worthy  of  concern,  was 
the  difficulty  researchers  In  graphics  had  in  building  on 
one  another's  work.  An  application  written,  for  example,  for 
a  storage  tube  display,  would  have  to  be  completely 
rewritten  for  a  raster  device.  The  changes  would  be  so 
numerous  that  equivalence  of  tne  programs  would  be 
impossible  to  assert.  Also,  the  full  duplication  of  a  piece 
of  work  simply  to  adapt  it  to  a  different  environment  was  a 


costly  process  in  terms  of  time  and  resources,  both  human 
and  macnine. 

B.  FORMATION  OF  THB  GSPC 

In  more  recent  years,  tnere  nave  been  some  attempts  to 
remove  tne  user  from  the  details  of  device  operation  by 
providing  high  level  software.  This  typically  tooic  the  form 
of  a  package  of  subroutines  callable  from  some  standard  nigh 
level  language.  Such  packages  did  remove  tne  need  for 
programmer  knowledge  of  some  of  the  device  operating  details 
(though  by  no  means  all  of  them)  but  each  package  was  still 
unique.  Thus,  though  a  step  forward  had  been  made,  programs 
written  from  different  grapnlcs  packages  were  still  not 
portable. 

The  next  step  in  tne  evolution  was  to  develop  grapnlcs 
packages  that  were  still  specific  for  particular  graphics 
devices  but  with  a  standard  Interface  to  tne  user  program. 
This  would  allow  transportation  of  user  programs  unchanged 
to  installations  where  the  "standard**  Interface  was 
implemented.  This  development  was  moderately  successful  out 
by  this  time,  areas  of  research  had  grown  up  around 
particular  classes  of  graphics  devices.  User's  of  tne 
various  classes  of  devices  all  had  their  own  idea  as  to 
exactly  what  form  the  application  program  interface  should 
take.  These  opinions  were  widely  varying  and  as  always,  were 
oriented  toward  the  device  capabilities. 
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The  various  "schools"  of  graphics  researcn  eventually 
realized  that  taere  were  vide  areas  of  agreement  in  taelr 
concepts  of  how  a  user  should  see  a  graphics  system.  Inis 
led  to  the  next  evolutionary  stride*  the  standardized 
graphics  package.  These  types  of  systems  were  designed  so 
that  not  only  would  the  application  program/package 
interface  be  fixed,  but  the  functionality  of  the  package 
Itself  would  be  unchanging.  The  need  for  individualized 
software  for  each  particular  device,  however  would  not  be 
removed.  This  task  wonld  be  accomplished  by  a  "device 
driver"  and  its  Interface  with  the  standard  package  would  be 
a  fixed  entity. 

The  first  neaningful  steps  toward  a  standard  graphics 
package  was  the  IFIP  Working  Group  5.2  Graphics 
Subcommittee's  Workshop  on  Graphics  netnodology  held  in 
Selllac,  Trance  in  1976.  Based  on  experience  with  existing 
machine  and  device  Independent  packages  like  GINO-F  and  GFGS 
the  subcommittee  laid  the  groundwork  for  the  movement  toward 
industry  wide  standardization.  Their  contribution  was  to 
outline  and  define  the  Issues  that  had  to  be  addressed  if  a 
standard  was  to  become  a  reality.  As  already  discussed, 
their  prime  concern  was  tne  issue  of  application  program 
portability.  Toward  this  end  their  recommendation  was  that  a 
study  of  the  structure  of  application  programs  was 
indispensable,  and  that  the  results  of  such  a  study  would 
drive  the  specification  of  a  graphics  standard.  Another 
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1 

outcome  of  tne  Selllac  meeting  ves  tne  assertion  tnat  tne 
separation  of  operations  concerned  with  creating  a  picture 
^  of  an  object  from  those  concerned  with  manipulating  tne 

object  Itself  was  essential.  Lastly,  the  Workshop  urged  that 
a  standard  graphics  system  specification  not  stand  alone. 
^  Along  with  the  detailed  design  should  be  included  the 

methodology  behind  its  development. 

In  1977  toe  ACM  Special  Interest  Group  for  Graphics 
^  (SIGGRAPH)  appointed  a  Graphics  Standard  Planning  Committee 

to  ieslgn  an  Industry  vide  graphics  standard.  Using  the 

recommendations  of  the  Selllac  Workshop  as  a  foundation,  the 
GSPC  designed  the  COBS  graphics  system.  Their  specification 
for  the  system,  and  the  methodology  that  led  to  it,  were 
■  published  In  August  1977.  An  updated  version  appeared  two 

years  later  incorporating  the  experience  gained  In  the 
Interim  and  extending  CORE  to  raster  devices. 

I 

i 


i 
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i  -  III.  ISSUES  CONSIDERED  IN  CORE  DESIGN 

la  tae  early  stages  of  discussion.  tne  Grapnics 
|  Standards  Planning  Committee  concentrated  on  clearly 

defining  tnelr  goal.  Tnelr  objective  was  to  design  a  general 
purpose  graphics  system  that  would  meet  the  needs  of  the 
j|  majority  of  graphics  programmers  and  would  be  simple  to 

Install  on  most  existing  Interactive  displays. 

It  is  essential  that  such  a  general  purpose  system  be 
i  simple.  This  principle  was  recognized  by  tne  GSPC  and 

strictly  adhered  to.  They  targeted  their  efforts  toward  the 
potential  users  with  the  Intention  of  promoting  well- 
j  structured,  comprehensible  software.  Syntax  was  considered  a 

less  complex  and  secondary  design  Issue.  The  committee  also 
sought  to  put  definite  bounds  on  the  scope  of  the  new 
system.  The  intention  was  to  provide  a  system  that  would 

offer  a  wide  range  of  capabilities,  but  not  at  the  cost  of 

losing  Its  appeal  as  a  general  purpose  tool.  Two  tradeoffs 
that  constantly  cropped  up  before  the  GSPC  were  simplicity 
vs.  wide  applicability  and  program  portability  vs.  machine 
efficiency. 

4.  FORMAT  OF  CORE 

Tne  GSPC  considered  three  approaches  to  development  of 

the  core  system.  One  possibility  was  to  create  a  complete 
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new  graphics  language.  A  second  c&oice  was  to  take  an 
|  existing  language  and  make  tne  core  system  an  extension  of 

It.  The  third  approach*  and  the  one  finally  settled  upon  vas 
to  hnlld  a  package  of  grapnlcs  subroutines.  There  are  a 
|  number  of  advantages  to  the  subroutine  package  as  opposed  to 

either  of  the  alternatives.  The  major  benefit  is  that  it 
requires  no  changes  to  either  the  language  or  the  compiler. 
System  development*  revision*  and  experimentation  will  have 
no  effect  on  any  other  software  at  the  Installation.  The 
primary  limitation  is  that  the  syntactic  structure  is 
extremely  limited  since  the  only  choice  in  this  urea  1$  the 
approach  to  parameter  passing. 

B.  DIGRESS  07  PORTABILITY 

The  degree  of  program  transportability  as  measured  by 
the  type  of  required  changes  vas  broken  down  Into  three 
general  categories: 

1)  The  absolutely  portable  program  which  when 
transferred  from  one  Installation  to  another  would  require 
no  changes  whatever  to  the  source  code.  Such  programs  are 
the  ultimate  goal  of  any  graphics  stundard. 

2)  Programs  that  require  only  editorial  changes  without 
modification  of  structure.  This  class  of  program  would 
require  adaptation  to  a  new  Installation  In  much  the  same 
way  that  non-graphics  programs  written  in  a  high  level 
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language  bare  to  be  modified  when  they  are  transported.  The 
changes  typically  are  tnose  necessary  to  adapt  to  sucn  local 
ldiosyncnrasles  as  different  character  sets.  These  changes 
do  not  require  a  grapnlcs  programmer  or  a  specialist  In  the 
particular  application.  Many  of  them  can  even  be  automated 
on  a  reasonably  good  text  editor. 

3)  The  least  portable  category  of  programs  would  be 
those  where  changes  to  the  program  structure  Itself  are 
required.  Such  changes  as  navlng  to  create  a  particular 
routine  to  draw  an  arc  to  replace  a  single  command  required 
by  a  more  powerful  device  fall  into  this  category.  Changes 
of  tnis  type  may  require  a  detailed  Knowledge  of  tne 
particular  installation  characteristics;  even  then  they  can 
be  somewhat  difficult  and  have  a  tendency  to  be  error  prone. 

Realisation  of  the  absolute  portability  goal,  was  not 
expected  when  the  OSPC  published  their  proposal.  The 
immediate  hope  for  the  CORK  system  is  that  it  will 
lrastically  reduce  tne  number  of  changes  required  in  an 
application  program  when  it  is  transported.  It  is 
anticipated  that  the  "routine”  changes  of  category  2  above 
will  be  required  in  source  code  but,  as  a  minimum,  the 
structure  of  the  source  program  should  remain  Intact. 

C.  SCOPE  OP  CORE 

Having  established  the  form  the  roposed  graphics 
standard  would  tate,  and  tne  results  that  could  be  expected 
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from  it.  the  committee  set  about  defining  the  scope  of  the 
project.  Recognizing  the  Selllac  works no p's  wisdom,  the  GSPC 
focused  on  "viewing"  as  the  essential  part  of  any  graphics 
system  (its  core,  hence  the  name)  and  treated  anything  not 
concerned  strictly  with  displaying  information  about  an 
object  as  outside  the  scope  of  the  standard.  This  is  not  to 
say  that  such  Issues  as  modelling  or  grapnic  arts  were 
Ignored.*  The  Intent  was  to  design  a  core  viewing  system 
upon  wnlcn  tflose  functions  dealing  with  abstract  objects  and 
relations  between  them  could  be  built. 

D.  VIEWING  STSTEM  CONCEPTUAL  MODEL 

Once  the  scope  of  their  task  was  defined,  the  committee 
developed  a  model  that  would  adequately  represent  their 
concept  of  tne  viewing  system  of  tae  standard.  Tne  viewing 
system  can  be  thought  of  as  a  "synthetic  camera”  positioned 
and  oriented  in  a  user  defined  "world  coordinate  system". 
The  display  on  the  output  device  would  be  a  "snapshot"  of 
whatever  was  in  the  camera's  field. 

Such  an  analogy  fit  well  the  rules  the  GSPC  had 
formalized.  The  "graphical  world"  was  considered  an  of  tne 
graphical  data  available  to  the  system.  What  would  show  up 
on  the  output  device  would  be  a  view  of  this  world  through 
the  eye  of  the  synthetic  camera.  The  camera  might  be  able  to 
take  in  the  entire  set  of  graphical  data  or  only  a  portion 
of  it.  depending  on  the  viewing  parameters.  To  take  an 
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imaginary  snapshot*  the  system  would  have  to  be  aware  of  the 
camera's  location  in  space*  its  orientation,  and  tne  amount 
of  a  particular  object  It  could  actually  photograph  (l.e. 
Its  clipping  volume).  Further*  at  tne  instant  tne  snapshot 
Is  taken*  none  of  the  parameters  related  to  the  object  beln* 
photographed  could  cnange.  It  must  be  remembered  that  what 
is  on  the  screen  Is  only  a  part  of  the  total  information  in 
tne  graphical  world. 

X.  GRAPHICAL  DATA  STRUCTURE 

Besides  deciding  how  to  display  an  object  In  the 
graphical  world  the  committee  had  to  establish  the 
particular  structure  to  be  used  to  represent  graphical  lata. 
The  simplest  approach  would  be  te  have  no  structure  at  all. 
Either  all  of  tne  graphical  data  Is  present  and  fixed  or  a 
new  graphical  world  will  have  to  be  created.  Thus,  one  could 
only  build  or  erase  an  entire  object.  One  displayed,  there 
would  be  no  changes  to  the  graphical  world.  Such  an  approach 
Is  very  easy  to  Implement  and  storage  is  not  a  major  Issue, 
since  after  tne  snapshot  is  taken*  there  is  no  further  need 
of  the  data.  Such  a  system  Is  Ideally  suited  to  hard-copy 
plotters  and  similar  devices  but  Its  drawback  is  tnat  it 
does  not  meet  the  needs  of  a  large  portion  of  graphics 
applications. 

Much  of  eraphics  is  concerned  with  bulldlne  an  object 
and  selectively  modifying  only  parts  of  it.  Tnls  requires 


first,  tbat  the  graphical  data  not  be  lost  after  it  is 
dlsplnyed  and  second,  that  it  be  "segmented"  in  such  a  way 
that  individual  pieces  can  bt  manipulated.  Since  there  is  a 
considerable  demand  for  such  structuring,  the  GSPC 
Incorporated  it  into  their  standard  proposal.  Their  concept 
is  that  graphical  primitives  (line  drawing,  text,  and  marker 
placements)  be  grouped  into  indivisible  and  unchangeable 
segments.  These  segments  are  then  be  combined  to  produce  an 
entire  object.  Thus  the  picture  can  be  modified  by  pieces 
through  the  deletion  and  addition  of  individual  segments. 

In  the  Interest  of  economy  and  flexibility  tne  CORK 
system  also  Implements  a  form  of  the  simpler  unstructured 
option,  for  the  body  of  users  concerned  vitn  storage 
efficiency  or  having  hardcopy  displays,  it  is  possible  to 
designate  segments  as  temporary,  k  temporary  segment  is  one 
that  would  generate  graphical  output  while  it  is  open,  but 
once  closed  the  segment  vould  be  automatically  deleted.  The 
next  "new  frame"  action  will  cause  it  to  be  lost  altogether. 
Iffeetlvely,  while  the  image  is  being  created  in  the  open 
temporary  segment  the  graphics  system  is  unstructured. 

inother  possible  structuring  of  graphical  data  would  be 
to  use  multi-level  units  to  define  tne  graphical  world.  In 
such  a  system,  a  "unit"  (analogous  to  a  segment)  vould  be  a 
collection  not  only  of  primitives  but  also  of  references  to 
other  units.  This  approach  was  considered  by  the  GSPC  to  be 


to  complex  for  toe  tulle  of  current  graphics  applications. 
Tnere  are  many  variations  to  its  implementation*  none  are 
easily  accomplished,  and  all  require  a  great  deal  of 
bookkeeping  overhead  since  a  chance  to  one  unit  may  ripple 
through  several  others  that  reference  it.  It  should  be  kept 
in  mind,  nowever,  tnat  if  suca  a  graphical  structure  is 
desired  it  is  possible  to  construct  it  using  tne  CORE 
system. 

F.  ATTRIBUTES 

With  the  structure  of  graphical  data  settled  upon*  the 
need  arose  for  defining  modifications  to  the  described 
object.  Besides  the  primitive  functions  already  mentioned,  a 
graphics  system  must  have  a  means  of  further  describing 
them.  For  example,  a  primitive  like  "line”  mlgnt  have 
characteristics  such  as  dashed  (style),  red  (color),  and 
double  thickness  (width).  Deciding  now  to  incorporate  such 
attributes  into  CORE  was  another  major  issue  facing  GSPC. 
Some  attributes  naturally  associate  themselves  with 
primitives,  like  line  style  and  width,  while  others  Just  as 
naturally  only  apply  to  whole  segments,  such  as  viewing 
angle  or  clipping  volume.  A  problem  arises  with  attributes 
that  are  likely  to  be  needed  for  both  primitives  and 
segments.  Color  is  a  typical  example.  The  ability  to  produce 
a  drawing  using  lines  of  several  different  colors  might  be 
desirable.  But  if  it  is  desired  later  In  the  program  to 


change  the  color  of  all  drawings  to  say  blue*  an  ambiguity 
arises  In  now  to  nandie  tne  multicolored  segment. 

The  GSPC  felt  that  resolution  of  such  ambiguities  within 
CORK  would  take  away  from  tne  simplicity  of  tnelr  system. 
Therefore  they  established  the  rule  that  no  attributes  would 
be  shared.  Attributes  would  be  specific  for  primitives  only 
or  for  segments  only.  The  former  would  be  "static” 
attributes  and  be  unchangeable  for  a  primitive  once 
declared.  Segment  attributes*  on  the  other  nand  would  not  be 
so  restricted.  These  "dynamic”  attributes  would  be 
changeable  to  meet  tne  user's  needs  at  any  particular  place 
la  the  program. 

The  decision  as  to  Just  which  attributes  would  be  static 
and  wnlcn  would  be  dynamic  were  based  on  two  criteria.  Tne 
first  being  that  primitive  attributes  would  be  those  things 
that  would  normally  be  recorded  by  a  snapshot  of  a 
particular  object.  Attributes  pertaining  to  the  image  as  a 
wnole  would  be  segment  attributes.  The  second  criteria  was 
that  an  attribute  would  be  dynamic*  (l.e.  a  segment 
attribute)  only  If  most  medium  performance,  refreshed 
display  device  architectures  supported  cnanglng  tne 
attribute  with  reasonable  ease  and  efficiency. 

5.  TWO  AND  THRU  DIMINSIONAL  GRAPHICS 

Along  with  the  questions  of  graphical  data  structure* 
the  Issue  of  how  to  treat  two-dimensional  and  three- 


dimensional  graphics  in  a  single  standard  had  to  be  decided. 
Initially  tne  inclusion  of  taree-dimensional  graphics  was  in 
question  since  it  necessarily  would  add  complexity  to  tne 
system.  It  was  decided  that  the  need  for  three-dimensional 
graphics  was  great  enough  that  its  exclusion  would  restrict 
tne  applicability  of  tne  standard  to  an  undesirable  degree. 

4  more  subtle  question  than  3D  inclusion  was  whether  to 
treat  2D  graphics  as  a  subset  of  3D  or  to  handle  the  two  as 
disjoint  sets  of  operations.  The  advantage  of  disjoint 
treatment  is  that  tne  2D  expression  would  not  be 
unnecessarily  complex  since  3D  information  would  not  have  to 
be  carried  with  tnen.  On  tne  other  hand  a  large  portion  of 
the  system's  routines  would  have  to  be  duplicated*  one  group 
specialized  for  2D  manipulation  and  another  for  3D. 

The  GSPC  chose  the  subset  approach  in  the  Interest  of  a 
unified  treatment  for  all  Images.  To  foster  simplicity  in  2D 
graphics*  they  established  that  the  z  axis  coordinate  would 
automatically  default  to  tnat  of  its  last  specified  value 
when  fitting  2D  operations  into  the  3D  format. 

H.  T  HYING  WANS  FORMAT  10  NS 

One  of  the  most  difficult  Issues  for  the  GSPC  to  decide 
was  how  to  treat  viewing  transformations  of  an  object.  There 
are  a  large  number  of  approacnes  to  this  problem  and  all 
have  a  certain  amount  of  merit.  When  considering  this 
particular  question  the  committee  chose  to  aim  for  maximum 


23 


system  generality.  Toward  tnis  end,  they  established  four 
criteria.  The  first  was  that  any  viewing  transformations  to 
&e  performed  would  be  declared  before  description  of  a 
particular  object.  No  transformations  within  a  segment  would 
he  allowed.  Secondly,  two-dimensional  transformations  would 
be  upward  compatible  to  three-dimensional  ones.  Third,  all 
general  planar  projections  would  be  possible  to  Implement, 
fourth,  parallel  and  perspective  projections  would  be 
consistent. 

In  tne  discussion  of  viewing  it  is  necessary  to  go  back 
to  the  synthetic  camera  model.  In  order  to  maximize 
generality  of  tne  viewing  aspect  of  CORK  tne  parameters 
under  investigation  were  tnose  concerning  the  location  of 
tne  synthetic  camera  in  space  and  tne  location  of  tne 
viewing  plane.  The  orientation  of  both  the  camera  and  the 
viewing  plane  must  also  be  considered.  It  should  be  apparent 
that  the  most  flexible  viewing  system  is  the  one  that  allows 
any  orientation  and  any  location  for  both  the  camera  and  the 
viewing  plane.  Restricting  the  positioning  of  one  or  both, 
limits  the  allowable  viewing  pyramid  and  results  in  failure 
to  meet  one  or  more  of  the  established  criteria. 

for  example,  suppose  tne  view  plane  were  restricted  so 
that  it  must  always  be  normal  to  the  direction  in  which  the 
camera  is  aimed.  In  such  a  case,  oblique  perspectives  are  no 
longer  possible,  which  is  a  violation  the  third  criterion. 


I.  LIT ELS  OF  CORE 

One  of  tne  final  issues  to  be  resolved  was  tne  structure 
of  tie  CORE  standard  itself.  The  question  was  whether  to 
establish  a  single  monolithic  standard  or  to  allow  a  number 
of  "standard  subsets"  of  a  parent  system.  Realizing  that  a 
very  extensive  system  might  be  well  beyond  the  needs  and/or 
resources  of  many  installations,  the  GSPC  settled  on  a  three 
level  structure.  The  lowest  level  would  be  restricted  to  the 
most  basic  needs  of  most  users,  stressing  ease  of 
implementation  as  well  as  economy  of  computing  resources. 
The  upper  two  levels  include  more  features  and  a  higher 
capability  with  correspondingly  more  difficulty  in 
Implementation.  Each  upper  level  of  CORE  Includes  all  of  the 
features  of  tne  level  below  it. 


If.  COM  SYSTEM  DESCRIPTION 


A.  OVERVIEW 

In  tne  previous  cnapter  most  of  tne  basic  terminology  of 
CORE  Has  been  Introduced.  In  tbis  chapter  tne  system  itself 
is  discussed  in  detail,  but  before  doing  so,  more 
terminology  must  be  introduced.  Tne  information  displayed  on 
tne  graphics  display  device  is  referred  to  as  a  picture .  The 
basic  building  blocks  of  pictures  are  output  primitives .  An 
output  primitive  is  a  line  or  sequence  of  lines,  a  non- 
drawing  move  of  the  cursor,  a  marker  placement,  or  a  string 
of  text.  A  number  of  output  primitives  are  grouped  together 
to  form  a  segment.  Each  segment  defines  a  single  object  *nd 
a  combination  of  one  or  more  objects  defines  an  image.  The 
view  of  an  image  can  be  thought  of  as  a  imaginary  camera 
snapshot  of  it.  To  obtain  a  3-D  projection  of  an  Image  the 
user  specifies  tne  imaginary  camera  position,  type  of 
projection  (perspective  or  parallel)  and  where  on  the 
display  surface  the  object  is  to  appear.  Different  views  are 
obtained  by  "moving”  the  synthetic  camera  in  space  relative 
to  the  stationary  object.  After  the  view  of  an  image  is 
determined  the  graphics  system  must  map  it  onto  the 
particular  device  selected  to  show  it.  The  CORE  system  does 
this  using  two  coordinate  systems.  Objects  and  images  are 
created  in  a  user  defined,  previously  specified  Wor^ 
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Coordinate  System.  Within  this  coordinate  system  the  part  of 
the  total  Image  tnat  Is  to  be  displayed  Is  framed  by  a 

window.  The  World  Coordinate  System  is  mapped  by  CORK  onto  a 
set  of  aoic&lU&l  iMQ.1-  NDC 

specification  defines  tne  viewing  area  on  the  selected 

graphics  device  that  will  be  used.  NSC's  are  specified  as 

fractions  of  tne  total  available  display  width  and  nelgnt. 
The  window  and  the  visible  section  of  the  image  in  it  are 
mapped  to  the  corresponding  location  in  the  normalized 
device  coordinates.  Once  the  image  Is  In  In  terms  of  the  NSC 
it  Is  a  simple  matter  for  tne  COBS  system,  knowing  the 
partlcnlar  device  characteristics,  to  translate  it  Into  a 
picture  on  the  screen. 

dny  graphics  system  must  have  a  means  of  controlling  its 
operating  environment.  In  the  CORK  system  this  is 
accomplished  by: 

1)  turning  clipping  on  or  off 

2)  selecting  view  surfaces  for  output 

3)  setting  initial  values  for  segment  and 
primitive  attributes. 

d)  establishing  error  handling  mechanisms 
To  support  the  control  functions  the  application  program  is 
given  tne  capability  to  Inquire  about  the  system  status, 
variables  and  device  capabilities.  There  is  a  "new  frame” 
function  for  screen  clearing  and  a  capability  for  grouping 
changes  to  the  picture. 


Output  primitive  functions  may  be  referenced  eltner  by 
a  segment  Identifier  or  a  special  "pick-id"  name.  The  pick- 
Id  Is  used  In  conjunction  with  a  pick  device,  whlcn  will  be 
discussed  later  In  the  chapter. 

To  allow  utilization  by  tne  system  of  specific  nardware 
and  Installation  features,  tnere  is  an  escape  mechanism.  It 
is  a  standard*  rigorously  constrained  function  that  allows 
the  CORK  system  to  take  advantage  of  the  non-standard 
capabilities  of  its  environment.  Use  of  the  escape  has  a 
price  in  that  It  takes  away  from  the  portability  of  the 
application  program. 

B.  OUTPUT  PRIMITIVE  JUNCTIONS 

Output  primitive  functions  are  the  operations  the 
programmer  uses  to  describe  objects  In  the  device¬ 
independent  Vorld  Coordinate  System.  Invocations  of  these 
functions  are  gathered  Into  segments  as  drawing  commands. 
Primitives  work  from  the  current  position  (gy ) .  which  Is  a 
drawing  location  In  vorld  coordinates.  It  Is  simply  a 
starting  point  for  application  of  the  function,  and  is 
Initialized  to  the  origin  upon  segment  creation. 

There  are  five  output  primitives:  single  and  multiple 
line  drawings*  text  display*  and  single  and  multiple  marker 
placements.  These  are  only  slightly  different  for  tne  two- 
and  three-dimensional  versions.  Coordinate  positions  may  be 
specified  as  either  relative  or  absolute*  but  toe  former  is 


merely  a  notatlonal  convenience.  It  does  not  necessarily 
generate  a  relative  positioning  command  to  tne  nardvare.  Tne 
concept  of  a  marker  In  tne  CORE  system  is  simply  a 
designation  of  a  position  In  world  coordinates.  A  particular 
cnaracter  appears  on  tne  view  surface  to  Indicate  tnls 
position  but  In  world  coordinates  tnere  is  no  sucn 
cnaracter. 

Tnree  kinds  of  text  are  supported  by  tne  CORE  system 
output  primitives:  string  precision,  cnaracter  precision 
and  stroke  precision.  Tne  main  purpose  of  string  precision 
text  is  to  supply  information  to  tne  operator.  Its 
generation  is  simple  and  efficient.  Cnaracter  precision  text 
is  used  when  it  is  important  tnat  a  cnaracter  strln*  occupy 
a  designated  space,  a  plot  axis,  for  example.  String  and 
cnaracter  precision  are  also  referred  to  as  low  and  medium 
quality  text,  respectively.  Botn  medium  and  low  quality  text 
output  primitives  take  advantage  of  nardvare  cnaracter 
generators,  if  available.  Stroke  precision,  or  nlgn  quality 
text  requires  a  different  approach.  Here,  tne  string  is 
treated  as  if  each  line  of  each  character  were  generated  by 
software  in  the  CORE  system. 


C.  SEGMENTS 


Segments  are  created  in  the  applications  program. 
Creation  of  a  segment  follows  a  simple  sequence.  Tne  Vorld 
Coordinate  System  is  defined  and  normalized  device 
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coordinates  are  specified.  If  desired,  tne  syntactic  camera, 
discussed  earlier,  is  positioned  to  establish  the  view  of 
the  object.  Next,  a  segment  is  "opened”  and  tae  object 
described  using  the  output  primitives.  After  completing  the 
object  description*  tae  segment  must  be  "closed  ".  To  modify 
a  piece  of  the  picture  a  segment  is  deleted  and  a  new  one 
created  to  replace  it.  Segments  are  of  two  types:  1) 
retained,  valca  are  typically  used  for  buffered  displays  and 
2)  temporary,  which  are  most  often  used  by  plotters.  As  one 
might  infer,  temporary  segments  are  used  only  once  to  create 
a  display  and  then  are  discarded.  Retained  segments  are  Jtept 
by  the  CORK  system  until  specifically  deleted.  Temporary 
segments  have  the  advantage  of  economy  of  memory 
utilization.  A  segment's  type  is  established  when  it  is 
created  and  remains  unchanged  for  the  life  of  tae  segment. 
Copying  one  segment  into  another  or  invoking  one  segment 
from  another  is  not  permitted  under  the  CORE  system. 

D.  ATTRIBUTES 

The  effects  of  output  primitives  are  modified  by 
assigning  attributes  to  taem.  For  example,  the  primitive 
"line"  has  an  attribute  "llnestyle"  which  has  values  "solid" 
and  "dashed".  Other  attributes  that  apply  to  primitives  are 
color,  character  size,  character  precision,  llnevldth  and 
more. 

SB 


Segments#  like  output  primitives*  also  nave  attributes. 
These  control  such  things  as  a  segment's  visibility* 
highlighting  vltnln  the  segment  and  Its  detectability  by  a 
pick  device.  This  last  Is  a  particularly  Important  segment 
attribute.  When  a  segment  is  detectable  and  a  pick  is 
enabled,  the  device  can  select  a  primitive  from  the  segment 
and  return  to  the  application  program  both  the  segment  name 
and  tne  primitive's  nlck-ld. 

Vita  the  exception  of  type,  segment  attributes  are  all 
"dynamic*'  in  that  they  may  be  changed  after  the  segment  nas 
been  created.  If  the  user  does  not  specify  attribute  values 
prior  to  segment  creation,  tne  COR!  system  provides  a  set  of 
default  values. 

Segments  are  assigned  attribute  values  from  a  table  of 
current  attribute  values  maintained  by  the  system.  The 
application  program  has  the  capability  to  Interrogate  and 
change  attributes.  Tor  primitive  attributes  changes  can  only 
be  made  while  the  segment  is  open*  segment  attributes,  on 
the  other  hand*  may  be  changed  at  any  time.  A  single 
attribute  cannot  apply  to  both  primitives  and  segments.  If 
certain  attributes  are  not  supported  by  hardware,  the 
options  are  to  either  simulate  taem  or  force  a  reference  to 
an  error  handling  routine.  The  choice  is  installation 
dependent. 

Besides  segment  and  primitive,  attributes  can  be 
classified  by  the  "space"  in  which  they  operate.  For 


31 


example,  text  attributes  describe  tne  text  regardless  of  its 
location  or  orientation.  They  are  said  to  define 
cnaracterlstics  in  "object  space".  On  tne  otner  nand,  line 
attributes  such  as  style  and  wldtn  are  related  to  views  of 
objects.  Depending  on  tne  location  of  tne  synthetic  camera 
these  attributes  of  an  object  may  appear  different  for  the 
same  value.  They  are  sail  to  operate  in  the  "picture  space". 

E.  TIEWING  TRANSFORMATIONS 

A  viewing  transformation  accomplishes  two  taslcs:  it 
specifies  how  much  of  the  world  coordinate  space  is  visible 
and  it  maps  visible  world  coordinate  pictures  into 
normalized  device  coordinates.  The  viewing  transformation 
taxes  a  world  coordinate  volume  (a  clipped  portion  of  a 
complete  display)  and  projects  it  onto  a  view  plane  in  world 
coordinates  defined  by  a  window.  Tne  projection  is  then 
mapped  into  a  normalized  device  coordinate  viewport,  and 
finally  to  the  physical  device  coordinates.  The  core  system 
avoids  a  problem  that  nas  occurred  in  tne  past  where  two- 
dimensional  objects  required  different  treatment.  2D  objects 
are  treated  as  a  subset  of  the  3D  objects.  When  a  Z 
component  is  not  specified,  a  default  to  the  Z  component  of 
tne  current  position  is  effected. 

Window  rotation  or  inclination  is  a  common  requirement 
for  many  applications.  In  tae  CORE  system  the  concept  is 
implemented  using  a  vlew-^n  vector.  This  vector  simply 
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points  to  tne  "straight  up"  direction  for  tne  window  wltn 
respect  to  tne  world  coordinate  orthogonal  X,  I*  and  Z  axes. 

T.  INPUT  PRIMITIVES 

Six  types  of  Input  devices  are  supported  by  tne  CORE 
system: 

PICKS:  Identify  an  output  primitive  by  its  segment 
name  and  pick-id. 

LOCATORS:  provide  world  coordinate  values  for  a  position 
on  tne  view  surface. 

VALUATORS:  provide  a  scalar  value. 

KEYBOARDS:  provide  cnaracter  strings. 

BUTTONS:  provide  a  means  of  selecting  from  several 
alternatives. 

STROKES:  provide  a  series  of  positions  to  tne 

application  program  In  normalized  device  coordinates. 

Input  for  interactive  graphics  is  accomplished  through 
logical  Input  devices.  These  devices  are  a  specified 
abstractly  In  the  application  program.  The  program  defines 
and  controls  them  in  a  way  unaffected  by  the  hardware.  The 
CORE  system's  task  in  Interactive  graphics  is  to  connect 
logical  Input  devices  to  an  available  piece  of  hardware  that 
will  accomplish  the  desired  function.  Logical  input  devices 
may  be  manipulated  in  the  following  ways: 

1)  Initialization/  termination  ' 

2)  Enabling/disabling 


3)  Event  queueing/  dequeuelng 

4)  Sampling 

5)  Associating  sampled  and  event  causing  devices  (tnls 
ties  values  provided  by  sampled  devices  to  events  caused  by 
event-generating  devices) 

S)  Echo  control 

Logical  Input  devices  fall  Into  two  mutually  exclusive 
categories.  Tney  are  eltner  sampled  devices  or  event  causing 
devices.  Stroke*  pick*  keyboard  and  button  are  event 
generating  devices)  locator  and  valuator  are  sampled 
devices.  Event-causing  devices  provide  signals  to  tne 
application  program.  For  eacn  event*  an  cvgnt  rppprt  is 
created  containing  data  related  to  tne  state  of  tne  device 
at  tne  time  of  tne  event.  Tne  CORE  system  enters  event 
reports  in  an  event  queue  for  later  use  by  tne  applications 
program.  To  get  state  information  about  sampled  devices*  tne 
application  program  must  query  tnem.  Tnese  devices  do  not 
generate  event  reports.  A  standard  feature  of  tne  CORE 
system  Is  to  ecno  automatically  all  operator  interactions 
unless  tnls  function  is  specifically  deactivated. 

G.  LSTELS  OF  CORE 

To  meet  tne  vide  range  of  Installation  capabilities  and 
requirements*  an  upward  compatible  tbree-level  structure  for 
tne  CORE  system  was  selected.  Tne  aim  was  to  accomodate  vnat 
were  considered  the  most  common  classes  of  equipment  and 


applications.  Tne  most  basic  level  of  tne  CORE  system  deals 
strictly  witn  output.  Tnere  is  no  interactive  capability  and 
tne  segments  are  of  tne  temporary  type  only.  This  level 
consists  of  tne  output  primitives  and  tnelr  attributes, 
viewing  transformations  and  device  controls. 

Tne  next  level  adds  tne  ability  to  retain  selected 
segments.  It  still  is  limited  to  output  only  operation.  The 
visibility  and  nignilgntlng  segment  attributes  also  are 
Included.  Tne  third,  dynamic  level,  allows  use  of  the  input 
capabilities.  This  is  the  level  at  which  interactive 
graphics  is  supported.  It  provides  all  the  functions 
Intended  to  make  up  tne  complete  core  system: 

1)  Output  primitives  and  tnelr  attributes 

2)  Tiewing  transformations 

3)  Device  control 

4)  Temporary  and  Retained  segments  and  tneir  attributes 

5)  Input  primitives 

6)  Image  transformations 

Level  three  is  further  divided  according  to  the 
capability  for  image  transformation: 

3A)  Two-dimensional  translation  only 

3B)  Two-dimensional  translation,  rotation  and  scale 

3C)  Tnree-dlmenslonal  translation,  rotation  and  scale 
is  with  all  of  the  levels,  these  sub-levels  are  also  upward 
compatible. 
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Complications  with  soon  a  level  structure  are  likely  to 
arise  at  Installations  where  tnere  is  a  combination  of 
different  graphics  devices.  What  Is  envisioned  for  sucn  a 
facility  Is  a  body  of  device  Independent  code  linked  to 
Individual  device  drivers.  The  latent  is  to  snare  as  mucn  of 
tne  Independent  eode  as  possible,  tnereby  keeping  as  much  to 
tne  objective  of  probability  as  feasible. 

H.  miROMMN?  INTERFACE  PROBLEMS 

Despite  a  ere at  deal  of  effort  to  make  tne  CORR  system  a 
stand-alone  entity,  operating  systems  and  programming 
languages  still  Impact  upon  It.  For  Instance,  tnere  is  no 
standard  way  to  mane  device  driver  routines  available  to  tne 
application  when  tbe  system  Is  Invoked.  Metnods  can  vary 
widely  depending  upon  computer  and  operating  system 
capabilities.  Another  problem  Is  tne  case  where  a  system 
message  is  sent  to  a  terminal  where  the  CORE  system  has  been 
Invoked.  The  state  of  the  display  may  be  changed  without  the 
system  beln*  aware  of  It.  The  consequences  of  this  depend  on 
the  situation,  but  system  reliability  will  certainly  be 
degraled. 

There  Is  as  yet,  no  definition  of  a  standard  Interface 
with  programming  languages.  It  is  hoped  that  as  more  Insight 
and  experience  is  gained,  a  standard  language  Interface  will 
be  developed  and  the  CORE  system  will  be  able  to  be  invoked 
from  more  than  one  language,  adding  a  new  dimension  to  Its 


portability.  Input/output  also  nas  problem  potential  if  the 
programming  language  and  tbe  CORE  system  are  operating  on 
tbe  same  device.  Resolution  of  tnis  Is  still  nigniy  language 
and  device  dependent. 


7.  t&!  7GM  APPROACH  Ifl  CORK 


Tne  Virtual  Graphics  Machine  (TGM)  is  Beil  Northern 
Research's  implementation  of  tne  CORE  graphics  system.  It 
vas  developed  on  an  IBM  3033  in  ANSI  standard  FORTRAN  and 
later  modified  to  operate  on  a  PDP-ll/70  under  tne  RSX-11 
operating  system.  7GM  is  a  FORTRAN  based  set  of  subroutines 
with  each  subroutine  corresponding  to  a  CORE  primitive 
invocation*  attribute  setting*  or  view  transformation.  Tne 
package  also  Includes  subroutines  for  control  purposes*  such 
as  Initializing  devices*  opening  segments  and  setting  up 
coordinate  systems. 

The  Intended  customer  market  for  TGM  is  installations 
with  low  and  medium  cost  "intelligent''  terminals  which  are 
capable  of  generating  graphical  output  from  fairly  high 
level  functions  and  primitives.  Terminals  not  accepting  such 
high  level  input  will  require  intermediate  software  to 
eltner  simulate  the  functions  or  break  tnem  down  to  lover 
level  primitives  compatible  with  tne  device. 

(Jnder  RSI-11,  VGM  exists  as  a  library  of  FORTRAN 
subroutines.  To  use  TGM,  tne  application  program  is 
created  independently  as  a  main  program  making  calls  to  the 
VGM  library.  The  application  source  code  is  then  compiled 
Independently.  The  connection  with  TGM  is  made  by  the  RSI-11 
Task  Builder.  The  application  object  file  and  tne 


appropriate  routines  from  tne  VGM  library  are  linked  into  a 
single  task  by  tbat  RSX  utility. 

Included  In  tne  VGM  library  is  tne  particular  subroutine 
that  establishes  communication  between  VGM  and  the  selected 
device.  This  segment  of  code  nas  to  be  created  specifically 
for  tne  installation  wnere  VGM  is  to  be  implemented.  Tnis 
routine*  S8LSTR*  is  the  only  executable  code  in  VGM  that 
interfaces  with  tne  device  driver.  Grapnical  data  is  passed 
between  VGM  and  the  driver  via  a  COMMON  block  of  memory. 
What  SELSTR  does  is  set  tne  necessary  flags  to  control  tne 
concurrency  between  the  application  task  (linked  with  VGM) 
and  tne  selected  device  driver  tasks.  Eacn  device  driver 
exists  as  a  separately  compiled  and  linked  task.  Under  RSX* 
before  invoking  any  driver  from  VGM  tnese  tasks  must  be 
INSTALLed  by  the  user. 

In  VGM*  syntax  is  a  very  minor  issue.  Since  tne  parent 
language  is  FORTRAN ,  and  the  entire  system  is  based  on  tne 
subroutine  call*  the  only  syntax  is  the  manner  in  which  the 
necessary  parameters  are  passed. 

It  should  be  emphasized  tnat  VGM  does  not  Implement  tne 
CORE  graphics  system  exactly  as  set  down  in  tne  1979  GSPC 
report.  There  are  a  number  of  differences*  which  may  be 
grouped  into  four  general  categories. 

A.  FUNCTIONAL  DIFFFRINCXS 

In  this  category  the  end  result  of  a  series  of 
operations  in  VGM  is  the  same  as  that  specified  by  CORE  but 


39 


the  mechanism  for  achieving  the  result  is  not  the  one 
specified  in  the  proposal. 

1 .  Segmg&iatl&i 

The  CORK  system  creates  a  retained  segment  or  a 
temporary  segment  with  a  single  function  specific  for  the 
particular  segment  type.  7GM  uses  a  two-step  process.  First, 
a  segment  type  is  established.  After  the  Invocation  of  the 
routine  to  do  this  any  segment  created  will  taice  on  the  type 
of  the  one  declared.  All  segments  created  will  be  of  the 
same  type  until  a  new  type  is  declared. 

Retained  segments  in  F&M  are  stored  in  Transformed 
Dlsnlay  Files  (TDF*s) .  The  TDF  contains  graphical 
information  that  is  ready  to  be  translated  into  a  device 
compatible  format.  All  clipping  and  transformation  has  been 
done  before  the  data  is  entered  in  the  TDF.  Should  the 
application  program  specify  an  operation  on  a  segment,  the 
entire  TDF  is  likely  to  be  changed.  Segments  that  are 
specified  to  be  temporary  do  not  cause  creation  of  a  TDF. 

2.  mti&ai&a 

Like  CORE,  7GM  partitions  attributes  according  to 
their  application  to  either  segments  or  primitives.  Both 
systems  further  divide  the  set  of  attributes  according  to 
their  changeability  within  the  program,  dynamic  attributes 
being  those  that  are  subject  to  change  by  tne  application 
program  after  their  Initial  declaration  and  static 
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attributes  being  those  that  are  not.  In  CORE  there  are  no 
dynamic  primitive  attributes.  7GM,  however,  does  have  a 
group  of  primitive  attributes  that  it  labels  as  "dynamic'’. 
Sach  member  of  the  set  of  7GM  dynamic  primitive  attributes 
is  also  a  member  of  the  set  of  static  primitive  attributes. 

In  VGM  a  static  primitive  attribute  is  one  that  is 
set  while  a  segment  is  open,  and  that  once  declared,  applies 
to  all  appropriate  primitive  Invocations  following  it  until 
the  segment  is  closed.  Further,  for  the  lifetime  of  that 
segment  it  will  always  apply  to  the  set  of  primitives 
created  with  it.  1  static  primitive  attribute  cannot  be 
overridden  by  any  other  setting  of  that  attribute  anywhere 
in  the  program. 

If  no  attributes  applicable  to  a  particular 
primitive  are  set  within  a  segment  then  dynamic  primitive 
attributes  may  be  assigned  outside  the  segment.  At  a  later 
tlmq  in  the  program  these  attributes  may  be  changed.  When  a 
dynamic  primitive  attribute  is  set,  the  segments  to  which 
the  change  applies  must  be  specified.  If  the  application 
program  does  not  set  either  dynamic  or  static  attributes  for 
some  primitives  then  default  values  are  used.  It  is  also 
possible  for  the  user  to  specify  his  own  set  of  default 
values . 

The  applicability  of  an  attribute  to  a  primitive  at  any 
particular  time  in  the  program  can  be  determined  by  the  rule 
that  user  specified  dynamic  primitive  attributes  always 


override  default  values  and  static  primitive  attributes 
always  override  dynamic  ones. 

3.  ZUfi  ZifiMlns  Surpass. 

The  flow  of  fraphlcal  information  from  a  segment  to 
an  output  device  is  viewed  by  7GM  as  a  "stream".  By 
manipulating  streams*  tne  user  carries  out  the  COBB 
SBLBCT/DBSSLEC?  and  BNABLE/DISAB1B  device  operations.  In  7GM 
wnen  tne  user  initializes  a  stream*  ne  is  picking  a 
particular  device  or  group  of  devices  for  output.  Devices 
are  assigned  to  a  specific  stream  as  part  of  7GM.  A  given 
stream  may  have  more  than  one  device  associated  with  it. 
Changing  tnis  assignment  requires  changes  to  the  7GM  source 
code  Itself.  Stream  initialization  by  tne  user's  subroutine 
calls  accomplishes  tne  necessary  operating  system  functions 
to  link  7GM  and  the  appropriate  drivers.  It  is  valid  for 
more  than  one  stream  to  be  in  use  at  any  given  time. 

After  initializing  the  required  treams  the  user 
then  selects  one  or  more  of  them  to  be  used  for  display. 
Once  a  stream  is  selected*  all  subsequently  generated 
graphical  output  will  be  displayed  on  the  devices  assigned 
to  that  stream  until  it  is  deselected.  There  is  no  way  to 
address  individual  devices  on  the  same  stream.  Stream 
operations  are  not  allowed  while  a  segment*  regardless  of 
type*  is  open. 


*'  cgotiiaaie  smsaa. 


7  CM  uses  an  extra  coordinate  system  in  translating 
grapnlcai  data  from  world  coordinates  to  tne  terminal 
Physical  Device  Coordinates  (PDC) .  Between  the 
transformation  from  Varld  Coordinates  to  Normalized  Device 
Coordinates*  PGM  taxes  clipped  graphical  data  and  maps  it 
onto  a  view  plane  In  flew  Plane  Coordinates  (7PC!i .  The  flow 
of  graphical  data  is  shown  In  figure  1. 
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figure  1.  flow  of  graphical  Information  through  coordinate 

systems 


5. 

In  the  CORI  specification  there  Is  a  static  segment 
attribute  called  lMAGS_TRANSfORMATION_TTPI  this  specifies  a 
maximum  allowable  level  of  transformation  that  can  be 
applied  to  a  given  retained  segment.  Tnere  are  four 
allowable  levels: 

a.  no  transf ormatlon 

b.  2D  translation  only 

c.  2D  translation*  rotation  and  scale 

d.  3D  translation*  rotation  and  scale. 


This  feature  is  hot  included  in  TOM.  The  transformations  of 
20  or  30  translation,  rotation  and  scaling  may  be  applied  to 
any  retained  segment  at  any  time  in  the  program. 

6-  tsii  giaLmliikaai 

In  CORI,  the  manner  in  which  text  is  displayed  on  a 
device  is  controlled  by,  among  others,  tne  attributes 
CHARPATH,  CHARJUST,  and  CHARUP.  The  first  attribute 
specifies  one  of  four  paths  in  the  view  plane:  up,  down, 
right  or  left.  As  the  sequence  of  text  is  output  CHARPATH 
determines  where  in  relation  to  the  last  character  the  next 
is  to  be  positioned.  The  first  character  is  always 
positioned  at  the  CP.  The  CHARJQST  attribute  is  a 
combination  of  directions,  again  la  the  view  plane,  which 
indicate  where,  in  relation  to  the  CP,  the  rectangle  defined 
by  the  output  text  string  is  to  be  placed.  Figure  2  gives 
the  possible  CP  locations. 
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Figure  2.  Possible  position  designations  of  CHARJUST 


The  text,  depending  upon  the  charjust  values  will  be  placed 
in  such  a  way  that  the  CP  will  be  at  a  junction  of  a 


vertical  and  a  norizontal  line,  A  particular  junction  is 
Identified  by  its  Horizontal  and  vertical  position  labels* 
e.g.  "left*  top"  *  point  a;  "center*  off"  *  point  b.  Tne 
CHARtJP  attribute  is  a  vector  from  tne  origin  in  World 
Coordinates  which  specifies  tne  "up"  direction  for  tne  text. 

These  three  COR!  attributes  are  not  specifically 
implemented  la  POM.  Instead*  their  functionality  is  Included 
in  tne  TGM  attributes  CBARPIAMI,  CEARSIZ!  and  CEARSPAC!.  The 
text  string  orientation  is  defined  by  the  CHARP1ANS  (a 
vector  in  World  Coordinates  originating  at  tne  CP)  and  a 
"string  extent"  vector.  The  string  extent  vector  is  obtained 
from  the  CBARSPAC1  and  CEARSIZ!  attributes.  Fleure  3 
illustrates  tne  components  of  these  two  attributes. 


a  *  CIARSIZI  x  component 
b  *  CEARSIZ!  y  component 
c  *  CEARSPAC!  dx  component 
d  *  CEARSPAC!  dy  component 

Figure  3.  CEARSIZ!  and  CEARSPAC!  attribute  components 


The  string  extent  is  tne  result  of  multiplying  the  rector 

by  the  number  of  characters.  originates  at  tne  CP. 

The  boxes  containing  the  text  characters  will  be  in  the 
character  plane  with  their  lover  left  corner  on  the  string 
extent  rector,  i  vide  rarlety  of  directions  the  text  may 
follow  stems  from  the  fact  that  ralues  for  the  attribute 
components  can  be  positlre  or  negatlre. 

7*  liSiiUUZ 

In  CORE  tnere  is  a  segment  attribute  called 
VISIBILITY  which*  If  "on",  means  to  display  a  specified 
segment  on  the  output  derice  and*  If  "off" ,  to  remore  it 
from  the  screen.  This  capability  also  exists  In  TOM  where  a 
segment  may  be  POSTed  to  make  it  risible  or  UNPOSTed  to 
remore  It  from  the  picture. 

B.  CORE  FUNCTIONS  NOT  IMPLEMENTED  BY  VGM 

The  following  list  of  CORE  functions  are  not  Implemented 
at  all  In  VGM: 

1.  pen  attribute 

2.  marker.symbol  attribute 

3.  plck.ld  attribute 

4.  naming  of  prlml tires 

9.  rlev_up  rector 

6.  some  inquiry  routines 

7.  terminate.*  disable.*  and  enable.group  routines 

8.  batch  update 


9.  escape  mechanism 

10.  highlighting 

11.  hierarchical  level  structure 

12.  acceptance  of  asynchronous  input 

C.  JUNCTIONS  IMPLEMENTED  BT  TGM  NOT  IN  CORE 
SPECIFICATION 

1 .  Primitives 

The  following  primitives  have  been  added  to  TGM: 

a.  rectangle 

b.  arc 

c.  polygon 

d.  flood 

The  flood  primitive  is  for  use  with  bit  mapped, 
color  devices,  flood  locates  the  CP  and  establishes  the 
smallest  area  surrounding  it  bounded  by  arcs  or  lines.  This 
area  is  then  filled  with  a  user  specified  color.  If  the  CP 
is  not  enclosed  then  it  is  possible  to  flood  the  entire 
display  surface. 

All iimaa 

Tor  terminals  capable  of  color  graphics  TGM  adds  a 
BACKGR0tJND_C0L0R  attribute  and  an  ADDITITI_M0DE  attribute. 
The  former  is  self  explanatory.  The  latter  determines  how  a 
declaration  of  any  new  color  attribute  is  to  be  treated.  If 
ADDITITE_MODE  is  "on"  then  the  bit  pattern  for  the  old  color 
is  logically  ORed  with  the  bit  pattern  for  the  new  color. 
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and  me  resulting  pattern  becomes  tne  value  of  tne 
attribute.  Otherwise  tne  new  color  bit  pattern  simply 
replaces  tne  old  one. 

&  BLINK  attribute  Is  Implemented  in  TGM,  vnlcn  is 
Intended  to  be  one  method  of  replacing  tne  COBS  system 
HIGHLIGHTING  attribute  wnlcn  nas  been  left  out. 

3.  0l&&£ 

In  TGM,  there  Is  a  mechanism  for  modifying  a 
segment  after  it  has  been  closed.  This  is  the  EXTSEG  feature 
which  effectively  re-opens  the  segment  and  allows  additional 
graphical  information  to  be  appended  to  the  existing  file. 
The  feature  only  allows  addition  of  information  and  requires 
that  the  CLOSEG  command  be  Issued  after  the  addition  is 
complete. 

If  a  graphics  device  that  is  currently  in  use  has 
both  input  and  output  capabilities*  TGM  will*  if  directed  by 
the  application  program,  "back  transform”  input  coordinates 
from  Physical  Device  Coordinates  to  World  Coordinates.  COBB 
will  only  back  transform  to  Normalized  Device  Coordinates. 

TGM's  error  handling  and  debugging  aids  offer  more 
than  is  required  by  the  COBB  proposal.  In  TGM  the  user  has 
the  capability  to  specify  toe  maximum  tolerable  error 
severity  and  the  maximum  tolerable  number  of  errors.  If 
either  maximum  is  exceeded*  tne  program  will  terminate.  Wnen 
errors  are  detected,  an  entry  is  made  into  an  error  trace 


file,  fms  file  Is  Intended  to  be  a  debugging  tool.  It 
contains  the  error  code  number,  a  brief  description  of  tne 
error,  the  relevant  parameters  Involved  in  tbe  error,  the 
name  of  tne  routine  In  vnlcn  tne  error  was  detected  and  tne 
result  of  tne  error  (corrected,  Ignored,  default 
substitution  or  program  termination). 

An  option  tnat  US PC  left  open  to  Imp  ementors  vas 
now  to  treat  non-graphlcal  data  sent  to  a  terminal  belne 
used  for  COBS  grapnical  output.  Typically,  tttls  mlgnt  be 
parent  language  I/O  In  tne  form  of  write  statements  or  a 
system  message  to  tne  particular  terminal.  In  YGM  tnere  is  a 
SIT_POSITION  function  which  Identifies  an  NDC  position 
specifying  wnere  non-grapnlcal  output  Is  to  appear  on  tne 
screen.  This  output  Is  affected  by  neither  attributes  nor 
tne  CP. 

0.  IQUIYALINT  FUNCTIONS  WITH  DIFFERENT  NAMES 

Tnls  Is  tne  simplest  category  of  differences  between 
COBB  and  YGM.  Belov  is  a  snort  list  showing  equivalent 
functions  In  CORI  and  YGM. 

£2&!  BIOS  a HSUS. 

cnarpreclslon  cnarquality 

detectability  pickablllty 

highlighting  blind 

world  coordinate  modelling  transformation 

transformation 


n.  THE  7GM  DBTICE  DR  I  TER 


The  device  driver  is  the  connecting  ling  between  7GM  end 
graphics  nerdwere.  Its  purpose  is  to  take  graphical  data 
from  TGM  via  the  designated  COMMON  storage  area  and 
construct  an  instruction  in  a  format  compatible  with  the 
particular  device  it  is  written  for.  Tne  software  for  the 
device  driver  is  divided  into  6  modules. 

A.  THE  DEfICE  CHARACTERISTICS  TABLE 

This  table  is  a  COMMON  block  of  variables  describing  the 
characteristics  of  the  graphics  device  for  which  the  driver 
is  written.  It  is  implemented  as  a  BLOCK  DATA  source  program 
and  is  accessed  by  all  of  the  executable  modules  of  the 
driver.  It  is  initialized  wnen  the  module  is  compiled  and  is 
treated  as  "read  only"  by  all  of  the  routines  referencing 
it. 

B.  THE  STREAM  INFORMATION  TABLE 

This  is  another  COMMON  block  of  data  wnicn  holds  tne 
current  value  settings  for  attributes  for  each  stream.  The 
table  is  updated  by  tne  driver  routines  as  the  values  are 
changed.  Vaen  the  BLOCK  DATA  source  file  is  compiled,  tne 
default  attribute  values  are  set. 


C.  THE  SUN  TIM  INFORMATION  TABU 

Tills  table,  like  the  stream  information  table  Is  subject 
to  continuous  update  bj  the  device  driver  routines.  It 
contains  the  buffer  that  holds  the  instruction  to  be  sent  to 
the  graphics  device.  Pointers  required  for  keeping  current 
positions  in  the  instruction  buffer  (CODBUF)  are  also  in  the 
run  time  information  table.  In  addition  there  are  variables 
for  the  identification  of  the  debug  file  and  several  host 
computer  related  values. 

D.  ROUT INIS  EXECUTING  TOM  PRIMITIVES  (OnLIBl) 

This  module  is  executable  code  that  is  intermediate 
between  VGM  and  the  device  instruction  creating  portion  of 
the  driver.  Its  routines  are  invoked  from  VGM  and  it  in  turn 
calls  routines  to  create  the  appropriate  data  to  fill 
CODBUF.  OnLIBl  is  graphics  device  independent  but  is  host 
machine  dependent.  Contained  in  OnLIBl  is  the  OnEXSC  routine 
that  is  the  only  executable  code  in  tne  driver  software  that 
communicates  with  VGM. 

E.  DEVICE  INDEPENDENT  LIBRAS!  OF  SHARABLE  ROUTINE*  (SESLIB) 

This  collection  of  routines  is  a  set  of  device 

independent  operations  that  are  optionally  available  to 
OnLIBl.  These  routines  perform  operations  like  projection  on 
a  plane,  clipping,  image  transformations,  line  style 
generation  etc.  For  highly  capable  devices  which  perform 
these  tasks  themselves  OnLIBl  would  not  reference  SEELIB  but 


instead  cause  the  specific  device  instructions  to  be 
generated.  For  devices  that  lack  some  of  these  features  in 
hardware,  SESLIB  provides  software  simulation. 

F.  DETICB  DEPENDENT  ROUTINES  GENERATING  INSTRUCTION  CODES 
(0nLIB2) 

This  set  of  subroutines  fills  the  instruction  buffer 
wltn  Instructions  and  data  specifically  formatted  for  tne 
target  device.  Bach  byte  of  CODBUF  must  be  precisely  set  to 
be  compatible  with  the  graphics  device.  Onl.122  builds  tne 
full  instruction  and,  when  complete,  causes  it  to  be  sent  to 
the  terminal.  The  communication  with  the  terminal  is  done 
with  MACRO  routine  QVRITE  which  uses  the  host  computer's  I/O 
communication  facilities  and  treats  the  graphics  device  as 
an  I/O  port. 

All  of  tne  device  drivers  share  tne  stream  information 
table  and  SCELIB.  Each  driver  Installed  with  TGM  however 
must  contain  each  of  the  other  four  modules.  The  inter¬ 
connection  of  the  various  device  driver  modules  is  shown  in 
Figure  4. 
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▼ii.  inmi  m  aasaiiiioNi  m  £2x222  21221 

A.  SOFTWARE 

As  stated  in  tne  Introduction*  tne  purpose  of  tnls 
research  was  to  lay  the  groundwork  for  a  detailed  study  of 
the  CORE  graphics  system.  A  great  deal  of  progress  has  been 
made  in  this  effort.  Tne  TOM  implementation  of  the  CORE 
system  is  installed  at  the  Naval  Postgraduate  School  and  is 
capable  of  operating  with  the  Tektronix  4014  storage  tube 
display  terminal.  The  system  has  passed  the  initial  stages 
of  testing.  Additionally*  algorithms  have  been  developed  and 
Implemented  on  a  limited  basis  for  expanding  the  7 CM 
software  to  interface  with  the  Ramtek  RM-9400  grapnics 
system.  These  portions  of  the  project  are  discussed  in 
detail  in  Appendices  A  and  B  respectively. 

A  less  tangible*  but  equally  valuable  result  of  this 
study  is  the  experience  and  insight  gained  wltn  both  CORE 
and  the  ?GM  implementation.  Appendix  C  is  one  product  of 
this  new  knowledge.  It  is  a  brief  tutorial  on  programming 
with  VGM  and  is  written  specifically  for  the  Naval 
Postgraduate  School  installation.  The  tutorial  is  not 
intended  to  replace  the  Bell  Northern  Research  User's 
Manuals.  It  is  meant  to  be  used  in  conjunction  with  them  and 
deliberately  avoids  details  which  can  easily  be  found  by 
referencing  them. 
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B.  COBB  ETALUATION 


The  COBB  system  is  currently  only  a  proposal  and  as  such 
it  is  intended  for  thorough  scrutiny  by  the  graphics 
community.  In  researching  tnis  subject  a  number  of  issues 
have  been  identified  which  may  provide  a  framework  for  an 
evaluation  of  tne  system.  This  collection  does  not  purport 
to  be  exnaustlve  but  is  presented  to  provide  a  base  for 
future  work. 

1 •  Portablll tr 

The  prime  issue  to  be  evaluated  is  that  of  program 
portability.  This  has  already  been  discussed  in  depth  in  the 
OS PC  proposal  and  summarized  in  this  report  in  Chapter  III. 
In  tne  course  of  this  study  some  different  perspectives  on 
the  problem  have  come  to  light.  It  appears  that  there  might 
be  hierarchical  levels  of  portability  other  than  those 
listed  in  the  SSPC  report,  graphics  devices,  computing 
systems,  operating  systems  and  COBB  implementations  are  all 


variables  in 

this 

area.  Another  vay 

of 

classifying 

the 

portability  of 

a 

program  might  be 

in 

terms  of  these 

environmental 

factors.  Por  example. 

some 

programs  may 

be 

portable  from  one  device  to  another  as  long  as  the  computing 
environment  is  not  chanted.  Others  may  survive  a  chanee  of 
computing  machinery  provided  the  operating  systems  are  the 
same.  Conversely,  changin*  operating  systems  rather  than 
computers  might  be  toe  defeating  factor  in  a  program's 


portability.  let  another  possibility  is  that  different 
implementations  of  CORK  may  be  the  reason  for  changes  in  a 
given  program. 

It  would  be  difficult  to  develop  furtner  tne  portability 
issue  from  this  point  of  view  until  a  variety  of 
environments  exist  for  side  by  side  comparisons.  The 
presentation  of  this  perspective  is  recorded  nere  so  that 
when  such  facilities  are  available  its  validity  can  be 
considered. 

2 .  Implementation  |X£ail 

To  gain  widespread  acceptance  the  CORK  system  must 
be  easy  to  Implement.  Criteria  are  needed  to  measure  tne 
difficulty  of  Implementation.  The  following  list  presents 
questions  which  may  serve  as  possible  evaluation  mecnanlsms 
for  this: 

a.  Can  the  implementation  be  reduced  to  simply 
following  some  hind  of  Implementation 
"algorithm"? 

b.  Does  tne  design  of  the  implementation 

favor  one  type  of  device  over  anotner? 

c.  Does  the  design  of  the  implementation 

favor  one  computing  environment  (either  hardware 
or  operating  system)  over  another? 

d.  What  tradeoffs  in  portability  have  to  be  made  so 
that  implementation  can  be  facilitated? 
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3.  g£Il££  Hm&iUiX 

4s  is  true  of  almost  all  standards  in  tne  computing 
industry  the  COR*  system  does  not  take  full  advantage  of  the 
nardvare  capability  of  many  installations.  It  was  never 
intended  to  meet  all  passible  needs.  Nonetheless  a  means  of 
assessing  the  loss  in  device  capability  under  tne  CORE 
system  should  be  established.  A  guideline  for  determining 
wnen  the  gains  from  using  CORE  are  outweighed  by  the  losses 
from  not  utilising  the  full  power  of  the  device  would  be  a 
nlghly  desirable  tool»  particularly  for  facilities 
generating  a  wide  range  of  graphics  applications  programs. 

4.  con  SmliUlI 

Perhaps  tne  most  difficult  and  controversial 
question  in  the  evaluation  of  CORE  is  whether  its 
capabilities  really  are  sufficient  for  most  grapnlcs 
programmers,  further,  how  adaptable  to  future  needs  will  the 
system  be?  Is  hardware  technology  likely  to  progress  to  a 
point  where  COR*  is  no  longer  adequate  as  a  standard?  Is  it 
likely  tnat  computer  grapnlcs  will  expand  into  areas  tnat 
COR*  was  never  Intended  to  serve?  Certainly  none  of  these 
issues  will  be  resolved  easily.  Each  question  in  Itself 
could  be  a  topic  for  detailed  analysis.  They  are  presented 
here  just  to  suggest  areas  for  further  study. 

C.  OUTLINE  07  CONTINUING  DETELOPMENT  OF  THE  NPS  SYSTEM 

In  the  course  of  this  study  some  ideas  have  been 
formulated  for  a  methodology  to  direct  continuing  work  on 
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tne  project.  Tills  is  only  one  worker's  point  of  view  and  it 
should  serve  as  a  guide  ratner  tnan  an  absolute  to  follow-on 
workers. 


1.  V6M 

|  Tne  first  order  of  business  snould  be  to  modify  tne 

Bell  Northern  Besearcn  test  routine*  AKPAK *  so  that  the  full 

range  of  TGH  functionality  can  be  verified.  This  would 
entail  construction  of  appropriate  overlays  for  tne  test 
package  so  that  the  large  amount  of  object  code  can  be 

accomodated  on  the  limited  PDF-ll/50  memory.  Once  this  is 

*  accomplished*  AKPAK  can  serve  as  a  benchmark  proeram  for 

testing  additional  drivers  that  are  added  to  7GM.  Using 
AKPAK  as  a  benchmark  should  also  aid  in  studying  other 
^  portability  Issues. 

2-  PgSlgg  Blilfili 

The  pattern  for  writing  tne  code  that  Interfaces  toe 
5  device  Independent  portion  of  a  software  driver  and  the  RM- 

9400  has  been  established.  Further*  it  has  been  partially 
Implemented  and  tested.  The  next  step  is  to  complete  the 
remaining  subroutines  in  toe  04LIB2  (device  dependent 
routines)  module  according  to  the  algorithms  provided  in 
Appendix  B.  Once  a  new  04LIB2  nas  been  built  it  can  be 

< 

incorporated  into  TOM  and  tested*  first  as  a  separate  entity 
using  the  provided  DDTIST  program  and  then  as  a  fully 
integrated  part  of  7GM  using  AKPAK. 

t. 
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By  no  means  would  tais  complete  wore  on  toe  Ramtek 
driver.  After  toe  04LIB2  wore  is  completed  toe  driver  would 
still  fall  far  snort  of  taxing  full  advantage  of  toe  power 
of  the  RM-9400.  A  topic  of  study  all  Its  own  would  be  the 
modification  of  the  "device-independent"  sections  of  the 
driver  code  to  put  the  sophisticated  features  of  the  RM-9400 
into  use. 

An  ancillary  project  would  be  to  develop  yet  another 
driver  for  a  new  graphics  device.  The  object  of  this  study 
would  not  be  to  merely  expand  the  capabilities  of  the 
existing  TG? 1  system.  What  It  Is  hoped  would  emerge  from  such 
research  is  a  pattern  for  writing  device  drivers.  Such  a 
formula,  if  It  exists,  would  be  a  very  useful  tool  for 
further  expansion  of  TGM  without  the  necessity  of  re¬ 
learning  already  established  techniques. 

3.  Eamsuin 

With  a  fully  operational  TGM  system  and  a  variety  of 
devices  available  for  use,  portability  testing  can  begin. 
The  suggestion  is  to  direct  the  work  along  lines  mentioned 
earlier  In  this  chapter  in  section  B.  After  varying  the 
graphics  devices  and  studying  the  system  behavior  over  a 
variety  of  them,  work  should  proceed  to  studying  program 
behavior  under  changes  in  the  computing  environment.  Otner 
operating  systems,  other  computers,  and  other  CORE 
Implementations  are  available  for  such  research.  This 
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The  aim  of  this  portion  of  the  project  was  to  gain 
insight  into  the  operation  of  VGM  and  to  install  a  wonting 
version  of  it  on  tne  Naval  Postgraduate  Scnool's  graphics 
facility.  Bell  Northern  Research  (BNR)  of  Ottawa,  Canada 
supplied  tne  school  with  a  tape  containing  tne  source  code 
for  VGM,  version  1.1.  and  two  device  drivers.  One  driver  was 
written  for  a  Chromatics  color  graphics,  raster  scan 
terminal  and  the  other  for  a  Tektronix  401X  storage  tube 
terminal.  A  Tektronix  4014  was  readily  available  at  Naval 
Postgraduate  School  and,  being  a  simpler  device,  was  deemed 
the  best  choice  for  installing  and  testing  VGM. 

On  the  same  tape  as  the  VGM  and  device  driver  software 
were  several  command  files  to  aid  in  installing  the  system. 
These  command  files  did  such  things  as  compile  the  source 
modules.  Install  libraries  and  build  tasks.  Their  inclusion 
was  Intended  to  save  some  user  time  and  effort  and  to  help 
avoid  erroneous  or  incomplete  system  commands  that  might 
arise  during  any  of  the  initial  stages  of  software 
installation. 

The  plan  for  implementation  was  the  following: 

A.  Compile  all  of  the  source  modules  making  up  VGM. 
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B.  Convert  the  FGM  object  code  into  a  FORTRAN  library  under 
RSI. 

C.  Compile  all  of  the  source  modules  malting  up  the  Tektronix 
device  driver. 

D.  Link  tne  object  code  from  tne  device  driver  compilations 
into  a  single  task  called  02DRIV. 

B.  Test  tne  driver  separately  from  IGM  by  using  a  test 
routine  supplied  by  Bell  Northern  Research. 

F.  Install  02DR IT  under  RSI  as  a  task  available  for 
concurrent  use. 

».  Test  TCM  itself  using  the  Bell  Northern  Research  supplied 
test  graphics  program  AEPAI. 

Before  any  of  the  installation  could  begin,  tne  software 
on  the  tape  had  to  be  made  easily  accessible.  This  was  done 
by  copying  it  onto  the  RSI  on-line  disk  storage.  A  copy  of 
the  BNR  software  may  be  found  under  directory  DP0: [201 ,211] . 
This  copy  of  tne  source  code  is  Intended  to  remain  unedited. 
Any  chances  to  the  code  during  7GM  installation  were  made  by 
transferring  original  copies  to  a  working  directory  and 
editing  there.  To  generate  object  code  the  modules  necessary 
for  FCM  and  the  device  driver  compilation  were  PIPed  to 
directory  BPS: [201,210] .  Once  the  source  code  was  available, 
the  command  file  7GMC0H.CMB  was  executed.  7GMC0M.CMD  nad  to 
be  modified  somewhat  to  make  it  compatible  with  toe  F4P 
compiler.  The  BNR  software  was  written  under  an  older  PDP 
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version  of  FORTRAN  so  tne  compiler  commands  nad  to  be 
adjusted  accordingly. 

In  all*  TOM  contains  12  output  modules  and  7  input 
modules.  Sacn  module  Is*  in  turn*  made  up  of  several 
subroutines  grouped  by  the  particular  function  tbey  perform. 
For  example,  tbe  output  module  INISTR  (INItialize  STRing  — 
named  for  tbe  first  of  tbe  component  subroutines)  contains 
16  separate  subroutines  all  navlng  to  do  vltb  eitner  stream 
or  segment  manipulations.  There  are  also  tvo  block  data 
modules  and  a  test  program. 

Once  object  code  vas  generated  for  all  of  tne  TGM 
routines*  command  file  TGMIIB.CMD  vas  executed  under  tbe  RSI 
LIBRARY  utility,  creating  a  library  of  all  tne  executable 
routines  concerned  vlth  input  and  output. 

Tne  compilation  process  vas  repeated  for  tne  source  code 
modules  for  tne  Tektronix  driver.  Command  file  02DC0M.CMD 
accomplished  this.  Tne  device  driver  modules  consist  of  tvo 
"libraries"  vhlch  manipulate  tbe  device  Independent 
information  coming  from  TGM.  A  tnlrd  library*  02LIB2*  does 
tbe  actual  creation  of  Instructions  to  tbe  Tektronix.  02LIB2 
is  tbe  portion  of  tbe  device  driver  that  links  TGM  and  the 
terminal.  There  are  also  some  block  data  modules  vnlcb  set 
up  communication  areas  betveen  tbe  device  driver  and  TGM  and 
also  provide  specific  device  parameters  where  needed  to  both 
TGM  and  tne  device-independent  portions  of  tbe  driver.  Tvo 
MACRO  modules  are  included  to  handle  input  and  output 
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communication  between  the  device  and  the  operating  system. 
The  rest  of  the  driver  related  modules  concern  themselves 
with  interfacing  the  device  Independent  parts  of  the  driver 
and  YGM  Itself. 

Like  YGM,  the  object  code  for  the  device  driver  modules 
are  built  into  a  library  under  RSZ  by  file  02DLIB.CMD.  This 
library  however  is  only  a  temporary  boldine  area  for  the 
driver  object  code.  It  is  referenced  by  tne  file  02DRI¥.C*D 
and  the  object  modules  are  linked  together  into  a  single 
task  called  02DRIT. 

Vlth  YGM  existing  as  an  object  library  and  02DRIY  as  an 
Individual  task  the  preliminary  work  is  done.  Testln*  is 
accomplished  In  two  stages.  The  first  is  testing  the 
functionality  of  the  device  driver  Independent  of  YGM.  The 
test  program,  02TSST,  was  provided  by  Bell  Northern  Research 
and  was  compiled  with  the  rest  of  the  driver  routines  and 
block  data  programs.  The  file  02TBST.CMD  links  the  test 
proeram,  the  driver  library,  and  the  block  data  Into  a 
single  executable  task  called  TBKTBST.  T1ZTRST  exercises  the 
driver's  functionality  fully  and  is  available  for  use  In 
directory  DP3: [201,210J . 

After  the  driver  was  satisfactorily  tested  alone,  the 
task  02DRXT  was  INSTALLed  under  RSZ.  The  INSTALL  feature  Is 
an  RSZ  utility  that  activates  a  specified  task  and  maxes  it 
available  for  Invocation  from  another  active  task. 
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The  next  step  is  building  the  7GM  test  task.  The  test 
routine*  AEPAK,  Is  also  supplied  by  BNR  and  is  intended  to 
thoroughly  test  7GM  and  any  selected  device  driver.  The 
command  file  provided  to  build  tne  AIPAC  task  is  7GMTKB.CMD. 
The  initial  attempts  to  build  the  test  program  resulted  in  a 
Task  Builder  diagnostic  indicating  tnat  not  enougn 
contiguous  disk  space  was  available  for  the  AKPAK  task.  This 
was  partly  a  result  of  the  fact  tnat  AKPAK  and  tne 
associated  7GM  library  routines  require  a  very  large  block 
of  disk  storage.  This  is  also  indicative  of  anotner 
potential  problem.  Since  the  ACPAK  test  is  such  a  large  one 
it  is  not  likely  to  fit  into  tne  available  core  memory.  It 
will  most  likely  require  construction  of  overlays  to  run  on 
the  limited  memory  resources  of  the  PDP-11/50  at  NPS. 

It  was  decided  that  at  least  for  tne  Initial  phase  of 
study  to  follow  a  somewhat  shorter  and  simpler  testing  path. 
Rather  than  become  involved  in  constructing  overlays  and 
possible  changes  in  the  structure  of  AIPAC,  a  more  limited 
test  program  would  be  written.  Since  one  goal  of  this  part 
of  the  work  was  to  get  an  operational  7GM  system  it  was 
decided  to  at  least  ensure  the  proper  interfacing  between 
the  user  program,  7GW  and  02DRI7. 

Toward  this  end,  a  much  simplified  test  program  was 
written,  called  7GMTST.  It  was  linked  witn  7GM  and  tne 
necessary  block  data  routines  by  file  7TST.CMD.  7GVITST 
exercised  several  of  the  2-dimensional  drawing,  move,  and 
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marker  primitives,  the  low  quality  text  capability  and  the 
SIT.POSITION  feature.  In  addition,  some  of  tne  device  and 
segment  control  functions  were  also  tested  since  their  use 
is  essential  for  any  TGM  operation. 

The  execution  of  TGMTST  was  quite  successful.  The 
drawings  on  the  Tektronix  screen  appeared  as  expected.  Tne 
task  is  available  for  use  under  directory  DP3: [201,210] .  To 
use  the  test  routine,  turn  on  the  Tektronix  4014  and  log  in 
under  HSX  by  the  standard  procedure.  Enter  the  proper 
directory  by  typing 

SIT  /UIC  -  [201,210] 

after  tne  RSX  prompt  (  >  ).  Next,  when  tne  prompt  appears 
issue  the  commands 

HNS  02DRIT 
>RGN  TGMTST 

Tne  test  program  will  execute  and  tne  resultant  grapnlcs 
will  appear  on  the  screen. 


66 


APPENDIX  B.  CONSTRUCTION  Q£  4  CfiUfil  25III5  S2E  SO  SAdSO 

5Jli?l 00 

A.  DEVICE  DRIVERS 

Bell  Northern  Research's  device  drivers  are  identified 
by  unique  integer  designations,  the  particular  integer  bein* 
incorporated  into  tne  driver  name  and  the  names  of  tne 
modules  that  comprise  them.  The  modules,  and  subroutines  in 
them,  specific  to  the  Chromatics  driver  all  begin  vltn  an 
01-  Identifier,  for  example,  01LIB2  or  01M0VE.  The  Tektronix 
4014  software  is  device  driver  #2,  thus  its  names  are  all 
prefixed  with  an  02-.  Also  provided  is  a  driver  which  shares 
tne  Tektronix  4014  code  but  is  to  be  used  with  tne  Tektronix 
4010.  This  uses  the  03-  prefix.  Only  the  03EXEC  (the 
Interface  with  tne  VGM  software)  routine  nas  tne  prefix,  tne 
rest  of  the  driver  uses  the  Tektronix  4014  code.  For  the 
routines  to  be  written  as  part  of  tnis  study,  tne  04-  prefix 
was  selected,  bein*  the  next  in  the  sequence. 

The  target  device  in  this  portion  of  the  study  was  the 
Ramtek  RM-9400,  a  very  powerful  and  sophisticated  color 
raster  scan  graphics  device.  Adaptation  of  a  similar  driver 
seemed  the  best  course  of  action.  The  Chromatics  grapnlcs 
terminal  is  also  a  color,  raster  device  though  not  nearly  as 
advanced  as  the  RM-9400.  Nonetheless  its  driver  is  readily 
available  and  is  already  adapted  to  the  PDP-ll/RSX 
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environment.  It  provides  a  good  starting  point  for 
developing  tne  Ramtek  software. 

Tne  Initial  Intent  In  tne  construction  of  a  device 
driver  for  tne  RM-9400  was  to  leave  tne  Cnromatics  driver 
Intact  as  far  as  possible.  Tne  module  SKBLIB,  wnicn  contains 
tne  device  Independent  hardware  feature  simulation  routines, 
was  left  unchanged.  The  Stream  Characteristics  Table  nad  to 
be  modified  only-  slightly  to  include  the  new  device.  The  Run 
Time  Information  Table  for  tne  Ramtek  is  simply  a  copy  of 
the  one  provided  for  the  Chromatics  driver.  Tne  same  is  true 
for  04LIB1  wltn  tne  exception  of  tne  04EXEC  routine. 
Modifications  to  04XXEC  were  very  slight.  Inclusion  of  the 
new  04EXBC  routine  did  necessitate  cnanges  to  tne  VGM 
software  in  the  INISTR  and  SSLSTR  (SELect  STRing)  modules. 

The  bulk  of  the  work  In  writing  tne  new  driver  will  be 
In  developing  a  new  04LIB2.  Creation  of  a  new  Device 
Characteristics  Table  Is  also  Important.  The  latter  requires 
an  item  by  Item  reviewing  of  tne  table  variables  and 
providing  the  appropriate  values  as  they  pertain  to  the  RM- 
9400.  Details  of  what  entries  should  be  made  are  in  the  BNR 
"Skeleton  Driver  Installation  Manual".  In  this  study  very 
little  of  the  RM-9400 's  capabilities  were  exercised  and  the 
importance  of  the  Device  Characteristics  Table  was  secondary 
to  getting  a  rudimentary  system  in  operation.  As  the  device 
driver  develops  Into  a  more  refined  form  and  incorporates 
of  tne  RM-9400's  capabilities,  the  Device 
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Characteristics  Table  should  be  reviewed  and  updated 
continuously. 

B.  RAMTEK  RM-9400  INSTRUCTION  FORMAT 

Before  writing  any  of  the  routines*  a  Knowledge  of  the 
format  of  an  RM-9400  Instruction  is  required.  The  RM-9400 
Instruction  Is  a  variable  length  buffer  of  16  bit  words.  The 
first  8  bits  of  the  first  word  contain  the  code  for  the 
function  the  device  is  to  execute.  Tor  exa  pie*  an  operation 
code  of  06H  (Ramtek  mnemonic  INIT)  initializes  the  device;  a 
code  of  35H  (Write  fector.  Unlinked  —  mnemonic  WVlJ)  is  a 
line  drawing  Instruction.  The  operation  code  determines  how 
much  more  of  the  Instruction  buffer  the  RM-9400  needs.  Tor  a 
very  simple  Instruction  like  INIT*  once  the  operation  code 
is  read,  the  rest  of  the  buffer  is  Ignored.  Tor  something 
like  a  line  drawing*  however,  the  device  will  require  a 
number  of  extra  words  of  Information  before  it  can  execute 
the  Instruction.  The  extra  words  will*  as  a  minimum*  have 
to  Indicate  the  end  points  of  the  line*  and  may  Include  the 
foreground  and  background  colors  as  well  as  the  line  style 
and  thickness.  Depending  on  the  operation*  some  of  the 
additional  instruction  words  are  essential  and  some  are 
optional.  In  most  cases*  If  a  piece  of  data  is  required  and 
Is  not  specified,  a  default  value  will  be  used.  The 
architecture  of  the  RM-9400  is  such  that  it  Is  possible  for 
the  user  to  specify  the  default  parameters  values. 


The  presence  of  additional  words  of  Information  is 
indicated  to  tne  Ramteic  by  flag  bits.  Tne  last  8  bits  of  tne 
first  word  are  the  primary  set  of  flags.  Only  three  of  these 
are  involved  in  extending  the  size  of  the  instruction.  The 
five  nigh  order  bits  of  the  low  byte  modify  the  execution  of 
the  operation  code  as  Indicated  in  the  following  table. 

bits  6  &  7  code  for  the  mode  of  addressing 

refresh  memory 

bit  5  selects  additive  mode  of 

text  output 

bit  4  reverses  foreground  and 

background  colors 

bit  3  sets  device  to  process 

bytes  in  a  word  in  reverse  order 

It  is  tne  tnree  lowest  bits  that  indicate  how  many 

additional  words  of  data  will  be  in  tne  instruction.  Bits  2 

and  1  each  indicate  whether  a  particular  "operand  flaw  word” 

will  be  in  tne  instruction  buffer. 

If  bit  1  in  set,  "operand  flag  word  #l"  (OFl)  will 
immediately  follow  the  word  containing  the  operation  code 
and  the  primary  flags.  OFl  is  another  set  of  flags  each  of 
which  corresponds  to  additional  pieces  of  information  in  the 
instruction.  The  setting  of  one  of  the  16  bits  in  OFl  means 
that  one  or  more  words  of  data  will  follow.  The  order  of  the 
additional  data  will  correspond  to  the  bits  of  OFl,  from 
lowest  to  highest. 

A  sample  bit  pattern  might  be 

0000  0001  0000  0010  ( 0102H ) 


Tbls  would  lBdlcate  that  two  additional  pieces  of  data  (one 
for  each  "l"  bit)  are  in  the  instruction  buffer  following 
on.  In  tnls  case  tae  two  bits  taat  are  set  mean  taat 
"foreground”  data  and  "line  dimension"  data  are  present 
(bits  1  and  8  respectively).  Tne  foreground  information  is 
simply  an  integer  index  to  a  color  table  in  Ramtefc  refresh 
memory  and  only  requires  a  single  word  of  storage.  Tne  line 
dimensioning  Information  is  more  complex  consisting  of  a 


pattern  code 

and  a 

repeat  code 

(Interpretation  of 

these 

codes  is 

not 

Important  to  the 

current 

discussion) 

and 

requires 

two 

words. 

These  two  words 

will  follow 

tne 

foreground 

word  in 

the  buffer. 

The  code 

that  the  RM' 

-9400 

would  execute  is  shown  symbolically  in  Figure  5. 
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then  0T2  will  immediately  follow  07i.  If  flag  bit  2  is  set 
and  flag  bit  1  Is  not,  taen  tae  word  immediately  following 
tae  operation  code  word  Is  0F2.  072  performs  exactly  tae 
same  task  as  071  except  taat  only  its  six  least  significant 
bits  are  used. 

Flag  bit  0  la  tae  operation  code  word  indicates  that 
text  or  numeric  data  will  follow  OFl,  072  and  taelr 
associated  parameters  If  present.  Tae  first  word  of  tnis 
data  will  always  be  an  integer  indicating  now  many 
additional  bytes  of  data  will  come  after  it. 

To  illustrate,  suppose  tae  user  wants  to  draw  a  line 
from  tae  pixel  at  screen  coordinates  100,100  to  tae  one  at 
500,500.  He  further  want  its  color  to  be  taat  of  #4  in  tae 
color  table  in  refresh  memory  and  ais  line  dimension  code  is 
given  by  the  words  0101H  and  0003H.  The  instruction  buffer 
would  be  that  saown  in  figure  6. 

To  a  rough  approximation  the  operation  codes  for  RM-9400 
instructions  correspond  to  T8M  primitive  and  device  control 
functions.  Similarly,  the  parameters  referenced  by  the 
operand  flag  words  correspond  to  attribute  values,  While 
this  is  not  always  the  case  it  provides  a  good  rule  of  thumb 
for  tae  initial  development  of  a  device  driver.  Taose  TGM 
calls  executing  a  primitive  or  control  function  will  cause 
an  operation  code  to  be  placed  in  tae  Instruction  buffer. 
Those  setting  an  attribute  will  cause  the  setting  of  flags 
and  loading  of  appropriate  parameter  values. 


C.  SITTING  ATTBIBUTKS 
1.  Storage 

wnen  an  attribute  is  set  it  does  aot  necessarily 
have  to  take  effect  immediately.  Therefore  memory  locations 
must  be  available  to  store  tne  values  of  attribute  settings 
until  an  appropriate  operation  code  using  them  is  loaded 


! 


i 


opcode  | flags 
0011  0101  i  0000  0011 


0/1 

0000  0001  0000  0010 


color  table  index 
0000  0000  0000  0100 


line  code  word  1 
0000  0001  0000  0001 

‘Tine  "code  word  2* 
0000  0000  0000  0011 

data  length  word-” 
0000  0000  0000  1000 

*~x  start  coordinate 
0000  0000  0110  0100 


y  start  coordinate 
0000  0000  0110  0100 

x  gnd  'coordinate 
0000  0001  1111  0100 

y”end”coordlnate 
0000  0001  1111  0100 


I 

j 

i 

I 


I 


I 


figure  6.  Instruction  buffer  for  line  with  specified  color 

and  style 
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Into  tne  instruction  buffer.  Tne  RM-9400  nas  tne  capacity 
for  setting  22  different  parameters*  eacn  one  corresponding 
to  a  bit  in  one  of  tne  operand  flag  words  (16  in  Oil  and  6 
in  072).  Not  all  of  tbe  parameters  that  are  entered  into  the 
Ramtek  instruction  are  limited  to  a  single  word.  Although 
some  parameters  do  require  only  one  word  there  are  others 
that  need  2  or  4*  and  in  one  case  12*  words  of  storage.  The 
total  storage  required  for  toe  22  parameter  settings  is  4? 
words.  A  global*  integer  array  of  47  elements  named  PARAM  is 
set  up  as  part  of  a  BLOCK  DATA  program  to  store  these  values 
as  they  are  set.  Two  additional  "read  only"  arrays  are  also 
part  of  that  BLOCK  DATA  subroutine.  Tnese  aid  in  referencing 
the  PARAM  array.  Integer  array  PRMPTR  of  length  22  contains 
Indices  to  the  starting  location  in  PARAM  wnere  a  particular 
parameter's  values  are  saved.  Bach  entry  in  PRMPTR 

corresponds  to  a  flag  in  one  of  the  operand  flag  words. 
Ilements  1  through  16  of  PRMPTR  contain  pointers  to  the  lata 
associated  with  bits  0  through  15  of  071.  Elements  17 
through  22  do  the  same  for  bits  0  through  5  of  072.  The 
second  array*  PRMSIZ,  is  a  parallel  array  to  PRMPTR.  Each  of 
its  integer  values  is  the  size*  in  words*  of  the  particular 
parameter  pointed  to  by  the  corresponding  element  in  PRMPTR. 
The  values  of  PRMPTR  and  PRMSIZ  are  fixed  at  compile  time 
and  remain  unchanged  throughout  the  program.  PARAM  is 
initially  set  to  all  zero  entries  and  gets  updated  as  the 
various  attribute  values  are  assigned. 


Tnere  are  also  two  logical  arrays  and  tnree  logical 
variables  involved  in  keeping  track  of  attribute  settings. 
T&e  elements  of  tne  logical  arrays  correspond  to  tne  bits  of 
0F1  and  0F2.  They  are  named  0F1ARR  and  0F2ARR.  If  a  bit  in 
either  OF1  or  0F2  is  to  be  set  by  a  particular  subroutine 
call  then  tne  element  in  0F1ARR  or  0F2ARR  tnat  corresponds 
will  have  a  FORTRAN  value  of  .TRUE..  Tne  logical  variables 
correspond  to  tne  lowest  tnree  bits  of  tne  primary  flag  set 
of  tne  Ramtek  instruction  operation  code  word.  For  bit  2 
tnere  is  0F2FL ,  for  bit  1  tnere  is  OFlFL  and  for  bit  0  tnere 
is  DFFL.  All  of  the  loelcal  variables*  including  tne  arrays 
are  initialized  to  .FALSI.. 

Finally*  tne  tnree  words  wnich  actually  control  the 
instruction  buffer  size  must  be  kept:  OFi,  0F2,  and  DLV 
(data  length  word).  Tbese  are  declared  as  integer  variables 
in  tne  BLOC!  DATA  subroutine  and  initialized  to  zero. 

Ulss  gaaanm 

When  a  subroutine  that  sets  an  attribute  is  called, 
several  operations  must  take  place*  not  necessarily  in  any 
particular  order.  One  of  the  required  events  is  that  the 
attribute  values  must  be  entered  into  tne  proper  location  in 
PARAM.  This  is  done  in  a  special  subroutine  called  04L0AD. 
Its  essential  part  is  a  DO  loop  vnlcn  fills  tne  array 
starting  at  tne  location  indicated  by  an  element  of  PRMPTR 
and  filling  tne  number  of  words  Indicated  by  tne 
corresponding  PRMSIZ  value.  Along  with  setting  tne  parameter 


values  a  f la*  martin*  the  fact  that  they  are  to  be  used 
must  also  be  set  in  either  OFlARR  or  0F2ARR.  Also,  toe  flag 
Indicating  either  0F1  or  0F2,  must  be  set,  so  either  0F1FL 


or  0 F2FI  becomes  .THUS.. 

The  code  for  any  subroutine  that  sets  an  attribute 
can  be  written  accordln*  to  the  following  algorithm: 


Input:  parameter  values 

1  be*ln  attribute  setting  subroutine 

•  set  OF1FL  or  0F2FL 

If  flag  In  OFlARR  or  0F2ARR  not  set  then 
set  OFlARR  or  0F2ARR  flag 

set  flag  in  OF1  or  0F2  by  adding  proper  power  of 
two 

end  if 

store  parameter  values  In  PARAM 

end 

Two  subroutines  have  been  written  that  carry  out  this 
|  process.  They  are  04C0LR  and  04BC0L.  The  source  code  for 

them  is  found  under  RSZ  on  the  PDP-11/50  In  directory 
DPS:  [301, lj.  The  subroutine  04L0AD  is  also  found  In  tnls 
J  directory. 

3-  IllllUg  XRRiimiRA  iRfXSI 

The  critical  subroutine  In  module  04LIB2  is  COPCOD. 
This  Is  the  one  that  controls  the  filling  of  the 
Instruction.  It  Is  Invoked  by  the  primitive  and  control 
subroutines  In  04LXB2.  The  routines  that  call  COPCOD  pass  as 
a  parameter  an  Index  to  an  array  containing  the  Rairtek 
operation  codes.  These  operation  codes  are  set  into  the 
array  OPCODB  at  compile  time.  They  are  designed  to  be  the 
Ramtek  equivalent  of  the  intended  TOM  function.  COPCOD  gets 
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the  actual  code  from  the  array  OPCODE.  The  operation  code 
and  the  primary  flags  are  then  combined  into  tne  first  word 
of  the  instruction  buffer.  COPCOD  also  causes  the  operand 
flagvords  (0F1  and  0F2),  their  parameter  values  and  the  data 
length  word  to  be  loaded  if  any  of  them  are  required.  The 
text  or  numeric  data  is  loaded  by  the  primitive  or  control 
routine  itself. 

The  following  algorithm  shows  the  operation  of 

COPCOD.  The  code  can  be  found  in  directory  DP3:[30l,lJ: 

input:  OPCODE  index 
begin  COPCOD 

get  actual  operation  code  from  array  OPCODE 
if  OFlFL  ■  true  then  set  flag  bit  l 
if  0F2FL  *  true  then  set  flag  bit  2 
shift  operation  code  to  upper  byte  of  first 
Instruction  word  (multiply  by  256) 
add  flagward  to  shifted  operation  code 
load  operation  code  word  into  buffer 
load  0F1  and/or  0F2  as  indicated  by  flags 
load  parameters  in  proper  order  from  PARAM 
load  data  length  word  if  necessary 
end 


As  with  attribute  setting,  all  subroutines  which  are 

primitive  functions  can  be  patterned  after  a  single 

algorithm.  Control  functions  can  follow  tnls  same  pattern 

though  they  typically  will  not  require  data  values  to  be 

placed  in  tne  instruction  buffer.  The  algorithm  is: 

input  data  values 
begin  function  execution 

set  DFFL  (data  flag)  if  appropriate 
set  bit  •  of  flaes 

set  data  length  word  (DLV)  to  number  of  bytes  of  data 
call  COPCOD  —  pass  OPCODE  index 
load  data  values 
execute  instruction 


end 


A  number  of  routines  nave  been  written  following 


[ 

! 
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tnls  algorltnm.  They  include: 

0400T  place  a  point  at  specified  coordinates 

04M0rZ  cnange  current  cursor  position 

04DRAV  draw  a  line  between  two  specified  points 

04SSTR  output  a  text  string 

04RSST  erase  tne  screen. 

All  can  be  found  in  directory  DP3:  [301, lj .  It  snould  be 
noted  that  tne  routine  04STR,  which  builds  an  instruction 
for  text  output*  inserts  an  extra  step  before  loading  the 
data.  04STR  receives  its  text  data  in  an  Integer  array  with 
one  alphanumeric  character  per  element.  The  RamteJt  requires 
textual  data  output  to  be  formatted  to  one  character  per 
byte.  Therefore  04STR  must  mate  this  conversion  before 
loading  the  data  into  the  buffer. 


*.  ISlilAS 

As  tne  routines  were  developed  tney  were  tested  for 
operability.  The  testing  was  at  a  very  low  level  simply 
checking  that  the  instruction  buffer  was  being  properly 
constructed  and  transmitted  to  the  RM-9400.  All  of  the 
routines  developed  in  tnls  portion  of  the  study  nave  been 
successfully  checked  in  this  manner.  The  test  programs  are 
modularized*  each  being  called  by  a  master  routine  called 
DUMTST.  The  individual  test  routines  are  named  LINTST  (LINe 
drawing  TeST) *  PTTST  (FolnT  placement  TeST)*  TXTST  (Text 
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output  TeST)  and  COITST  (COLor  selection  TeST).  Tneir  source 
code  can  be  found  in  directory  DPS : 1301 , lj . 

All  of  tne  routines  ieveloped  were  originally  part 
of  tne  01LIB2  nodule  of  tne  Chromatics  driver.  A  copy  of  tne 
original  software  is  available  in  ilrectory  DP3:[5,3].  After 
modifying  tne  names  to  conform  wltn  tne  selection  of  #4  as 
tne  identifier  for  tne  new  device  driver  eacn  subroutine  was 
removed  from  the  module  and  treated  as  a  separate  entity. 
Tnls  was  done  for  ease  of  editing  and  troubleshooting.  To 
support  tnls  process  command  files  were  created  to 
facilitate  repetitive  compilation  and  tasic  building 
operations.  Tne  files  C0MP.CMD  and  TCOMP.CMD  in  directory 
DP3:  [301,1]  cause  tne  compilation  of  all  tne  driver  software 
and  all  tne  test  software,  respectively.  Pile  DUM.CMD  builds 
tne  test  task  DUMTST.TSK,  by  linking  tne  modified 
subroutines,  tne  BLOCK  DATA  programs  and  the  test  routines. 

Among  tne  test  routines  some  snort  pieces  of  code 
nave  been  included  to  accomodate  testing.  Tne  Important  ones 
are  RMINIT,  which  inserts  tne  color  table  into  the  Ramtek 
refresh  memory,  and  BXGTXT,  which  causes  text  output  to  be 
printed  in  a  larger  than  normal  format  for  viewing  ease. 
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APPENDIX  C.  PROGRAMMING  WITH  PGJ1 


Graphics  programming  using  PGM  Is  actually  a  niePly 
specialized  use  of  FORTRAN.  Because  of  tnis,  all  tne  rules 
of  PDP-11  FORTRAN  apply  as  well  as  those  of  the  grapples 
system.  When  using  PGM  the  programmer  venerates  a  main 
program  which  references  a  library  of  grapples  subroutines. 

A.  SETUP 

PGM  is  Initialized  by  tnree  essential  statements.  First 

CALI  I  NIT 
(INITlaiize) 

starts  tne  PGM  session.  It  sets  tPe  variables  required  by 

botn  tne  operating  system  and  PGM  itself.  Tne  routine 

ensures  that  eacP  time  PGM  is  Invoiced  it  is  in  tne  same 

starting  state.  Immediately  following  tnis, 

CALL  INISTR(n) 

(INItlallze  STReam) 

activates  the  device  dependent  driver  software  for  stream 
'n'.  It  sets  device  parameters  and  uses  the  operating  system 
process  nandling  capabilities  to  allow  application  program 
access  to  tae  particular  device  or  devices  on  tne  stream. 
Lastly* 

CALL  SELSTR  (nl) 

(SELect  STReam) 

directs  all  grapnlcs  output  to  stream  'nl'.  If  anotner  CALL 
SELSTR  (n2)  Instruction  is  encountered  before  a  CALL 
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DlLSTR(nl)  instruction,  tne  grapnics  output  will  go  to  both 
streams  nl  and  n2.  It  is  mandatory  tbat  eacn  stream  be 
prepared  by  a  CALL  INISTR(n)  before  it  is  selected  by  a  CALL 
SELSTR  (n). 

B.  EN7IR0NMENT  SPECIFICATION 
1.  The  Coordinate  System 

In  7GM,  the  user  defines  his  graphical  world  in 
arbitrarily  selected  "world  coordinates".  These  coordinates 
are  tne  medium  through  which  he  communicates  positional  data 
to  the  system.  7GM  processes  those  world  coordinates  through 
a  series  of  viewing  transformations  and  eventually  derives 
"normalized  device  coordinates"  (NDC).  The  NDC's  are  real 
values  ranging  from  0.0  to  1.0  and  are  mapped  onto  the 
physical  device  selected  for  viewing.  A  picture  in  NDC  is 
independent  of  any  particular  graphics  device. 

For  7GM  to  properly  execute  the  string  of  required 
coordinate  transformations,  tne  Normalized  Device  Coordinate 
System  must  be  specified  before  World  Coordinates.  With 

CALL  N DCS PC  (nstrm,  width,  height) 

(Normalized  Device  Coordinate  Specification) 

a  rectangular  portion  of  tne  view  surfaces  of  terminals  on 
stream  'nstrm'  is  defined.  'Width'  and  'height'  are  real 
numbers  ranging  from  0.0  to  1.0.  They  indicate  the  relative 
part  of  that  dimension  of  the  view  surface  that  is  to  be 
used.  One  or  the  otner  must  be  1.0.  Therefore,  el-ner  tne 
full  screen  width  or  the  full  screen  height  will  be  used. 
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The  remaining  dimension  will  be  proportionately  adjusted.  1 
statement  such  as 

CALL  NDCSPC  (1,1.0, .75) 

will  set  up  the  devices  on  stream  #1  so  that  a  viewing  area 
using  the  full  width  of  the  screen  is  made  available.  The 
height  will  be  3/4  as  large  as  the  width  if  that  much  is 
available.  If  a  dimension  specification  is  too  laree,  the 
maximum  available  is  used.  The  NDCSPC  command  normally  is 
used  only  once  for  each  stream. 

2.  The  View  Surface 

After  setting  the  total  viewing  area  available, 
"viewports"  are  assigned  to  the  streams  by 

CALL  VIEW  (nstrm,  xmin,  ymin,  xmax,  ymax) 

A  viewport  is  a  portion  of  the  available  surface  (NDC  space) 
that  will  be  used,  up  to,  but  not  exceeding,  the  total 
declared  surface.  'Xmin',  'ymin',  'xmax',  and  'ymax'  are  NDC 
values  and  must  be  within  tne  bounds  specified  in  the  NDCSPC 
call.  A  viewport  declaration  stays  in  effect  until  a  new  one 
is  declared.  The  viewport  may  be  changed  as  often  as  tne 
user  desires  in  the  main  program. 

The  "window"  is  the  counterpart  of  the  viewport  in 
the  world  coordinate  system  and  is  set  by 

CALL  WINDOW  (nstrm,  xmin,  ymin,  xmax,  ymax) 

The  parameter  values  except  for  'nstrm'  are  in  World 
Coordinates  and  are  arbitrarily  selected  by  the  user  to  meet 
his  requirements  for  clipping  and  image  transformations. 


This  Is  the  part  of  World  Coordinates  that  tne  picture  Is 
created  In.  The  window  is  the  work  area  of  the  programmer. 
For  display,  the  clipped  and  transformed  images  in  the 
window  are  mapped  to  the  NDC  space  defined  by  the  viewport. 
3.  Background  Color 

On  color  capable  devices  the  last  environment 

setting  operation  is  to  define  tne  background  with 

CALL  BCICOL(ival) 

(BaCI*round  COLor) 

to  set  the  attribute  and 

CALL  BRASS 

to  brine  it  up  on  the  screen. 

Tne  current  version  of  FGM  allows  selection  of  one 
of  only  eight  colors  available.  Selection  is  done  by 
specifying  an  integer  value  between  0  and  7  for  'ivai'.  The 
default  color  table  contains  black,  blue,  green,  cyan,  red, 
magenta,  yellow,  and  wnlte,  in  that  order. 

C.  CREATING  A  PICTURE 

With  the  devices  initialized,  and  the  environment  set, 

the  next  step  is  to  open  a  segment.  To  do  this  the  type  of 

the  intended  segment  must  first  be  declared  by 

CALL  SEGTYP  (itype) 

(SEGment  TTPe). 

An  'itype'  value  of  1  indicates  tnat  all  subsequently 
created  segments  will  be  non-retained.  A  value  of  2  means 
tnat  they  will  be  retained. 


83 


if ter  tne  type  aas  teen  established,  tne  segment  is 
opened  with 

CALL  CRESEG  (nseemt) 

(CREate  SEGment). 

'Nsegmt'  is  an  integer  value  tnat  uniquely  identifies  tne 
particular  segment.  Once  tne  segment  is  open*  tne  user 
creates  nis  image  ty  invoicing  primitives  and  assigning 
attributes.  Any  primitive  attribute  values  declared  before 
closing  the  segment  are  static.  Declaration  of  segment 
attributes  is  not  allowed  while  a  segment  is  open.  As  eacn 
primitive  is  executed  its  contribution  to  the  total  image 
will  be  displayed.  Vfnen  tne  particular  image  is  completed, 
tne 

CALL  CLOSEG 
(CLOse  SEGment) 

instruction  is  Issued.  It  is  not  necessary  to  specifically 
identify  tne  segment  being  closed,  since  only  one  is  allowed 
to  be  open  at  any  given  time. 

After  closing  a  segment,  a  number  of  options  are  open  to 
the  user.  He  may  terminate  tne  session  by  normal  FORTRAN 
procedures  or  ne  may  continue  on  and  manipulate  devices, 
streams  and  segments.  He  may  alter  dynamic  attributes  and 
create  additional  segments  subject  to  tne  limitations  of  PGM 
and  FORTRAN. 

D.  EXECUTING  THE  PROGRAM 

After  creating  the  source  code  for  a  PGM  program  it 
should  be  independently  compiled  into  an  object  file. 
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Incorporating  the  user  file  and  the  7SM  library  into  an 
executable  taste  requires  the  following  command  sequence  to 
be  Issued  to  the  RSX  Taste  Builder  (for  purposes  of  the 
example,  MAIN  is  selected  to  be  the  name  of  the  user's 
program ) : 

TKB>  MAIN/CP/FP , 7SM/-SP*7GMLT /MP 
ASG  »  ST:  1 
ASS  *  ST:  2 
ASS  «  ST:  4 
ASS  «  TI:  5 
ACTFIL  »  3 
MAXBUF  -  90 
FMTBOF  *  80 
// 

Before  executing  the  taste  (now  stored  in  file  MAIN.TSK)  it 
is  necessary  to  INSTALL  the  device  drivers.  For  each  stream 
that  will  be  used  by  MAIN.TSK.  The  MCR  command  to  RSX  is 

>INS  OnDRIV 

where  'n '  is  the  integer  identifier  for  the  particular 
driver.  Tne  command 

>RON  MAIN 

will  execute  tne  user's  graphics  program. 
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